From nobody Thu Jan 2 09:12:43 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF431120806 for ; Thu, 2 Jan 2020 09:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 MS_3xpYHPasJ for ; Thu, 2 Jan 2020 09:12:40 -0800 (PST) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (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 D6D10120804 for ; Thu, 2 Jan 2020 09:12:39 -0800 (PST) X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id ED3B78C1D1C for ; Thu, 2 Jan 2020 17:12:38 +0000 (UTC) Received: from mail.myfast.site (100-96-86-164.trex.outbound.svc.cluster.local [100.96.86.164]) (Authenticated sender: dxszz3qpvg) by relay.mailchannels.net (Postfix) with ESMTPA id C27E48C1761 for ; Thu, 2 Jan 2020 17:12:37 +0000 (UTC) X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net Received: from mail.myfast.site ([TEMPUNAVAIL]. [81.19.215.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 02 Jan 2020 17:12:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dxszz3qpvg|x-authuser|jonathan@hansfords.net X-MailChannels-Auth-Id: dxszz3qpvg X-Stop-Harmony: 1aace054364eb7c1_1577985158643_2792404361 X-MC-Loop-Signature: 1577985158643:551386612 X-MC-Ingress-Time: 1577985158643 Received: from hansfords.plus.com ([84.92.116.209]:56086 helo=[192.168.54.20]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1in41O-0004ug-Nk for netmod@ietf.org; Thu, 02 Jan 2020 17:12:30 +0000 From: Jonathan To: netmod@ietf.org Date: Thu, 02 Jan 2020 17:12:30 +0000 Message-Id: Reply-To: Jonathan User-Agent: eM_Client/7.2.36908.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBE0AFCB30-76BB-4E27-86D0-BA1C23B9894F" X-Antivirus: Avast (VPS 200102-0, 02/01/2020), Outbound message X-Antivirus-Status: Clean X-AuthUser: jonathan@hansfords.net Archived-At: Subject: [netmod] Clarifications re RFC 8342 NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 17:12:42 -0000 --------=_MBE0AFCB30-76BB-4E27-86D0-BA1C23B9894F Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have been reading through RFC 8342 and have a number of questions I=20 couldn't resolve after a couple of passes through. Can anyone advise? The RFC states "The startup configuration datastore may not be supported=20 by all protocols or implementations", "the candidate configuration=20 datastore may not be supported by all protocols or implementations" and=20 " MUST be supported if the device can be configured via=20 conventional configuration datastores". I can find no explicit guidance=20 on:The intended configuration datastore: The RFC does state, "Whenever=20 data is written to , the server MUST also immediately update=20 and validate ." Is mandatory for NMDA-supporting=20 servers that support ?The operational state datastore: The RFC=20 does state it is "a read-only datastore that consists of all "config=20 true" and "config false" nodes defined in the datastore's schema" and=20 that "the datastore schema for MUST be a superset of the=20 combined datastore schema used in all configuration datastores ...". Is=20 mandatory for NMDA-supporting servers?RFC 8525, section 1=20 states, "For backwards compatibility, an NMDA-supporting server SHOULD=20 populate the deprecated "/modules-state" tree in a backwards-compatible=20 manner."That suggests an NMDA-supporting server SHOULD be=20 backwards-compatible with a non-NMDA-supporting client. Is that=20 correct?Can an MMDA-supporting client be backwards-compatible with a=20 non-NMDA-supporting server?I can't find any mention of YANG version 1 in=20 RFC 8342. Is it safe to assume NMDA is compatible with YANG version 1=20 modules? Thanks, Jonathan --------=_MBE0AFCB30-76BB-4E27-86D0-BA1C23B9894F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have been reading through RFC 8= 342 and have a number of questions I couldn't resolve after a couple of pas= ses through. Can anyone advise?
  1. The RFC states "The startup configuration datastore may not be s= upported by all protocols or implementations", "the candidate configuration = datastore may not be supported by all protocols or implementations" and "&= lt;running> MUST be supported if the device can be configured via conven= tional configuration datastores". I can find no explicit guidance on:
  2. <= ol style=3D"list-style-type: lower-latin;">
  3. The intended configuration d= atastore: The RFC does state, "Whenever data is written to <running>, = the server MUST also immediately update and validate <intended>." Is = <intended> mandatory for NMDA-supporting servers that support <ru= nning>?
  4. The operational state datastore: The RFC does state it i= s "a read-only=C2=A0datastore that consists of all "config true" and "confi= g false" nodes defined in the datastore's schema" and that "the datastore s= chema for <operational> MUST be a superset of the combined datastore= schema used in all configuration datastores ...". Is <operational> ma= ndatory for NMDA-supporting servers?
  • RFC 8525, section 1 state= s, "For backwards compatibility, an NMDA-supporting server SHOULD populate= the deprecated "/modules-state" tree in a backwards-compatible manner."
    1. That suggests an NMDA-supp= orting server SHOULD be backwards-compatible with a non-NMDA-supporting cli= ent. Is that correct?
    2. Can an MMDA-supporting client be backwards-co= mpatible with a non-NMDA-supporting server?
  • I can't find any m= ention of YANG version 1 in RFC 8342. Is it safe to assume NMDA is compatib= le with YANG version 1 modules?
  • Thanks,

    Jonathan
    --------=_MBE0AFCB30-76BB-4E27-86D0-BA1C23B9894F-- From nobody Thu Jan 2 10:37:15 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFD91200F7 for ; Thu, 2 Jan 2020 10:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 0iT3ZogvWUTd for ; Thu, 2 Jan 2020 10:37:10 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140051.outbound.protection.outlook.com [40.107.14.51]) (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 2B55512006F for ; Thu, 2 Jan 2020 10:37:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iLKmuzBdv1J/q0NANUva8s8NiU3Pjy21RwBCgDG2KOTWTyWWssDoQwn3NFc2kRueAqMaZz4fV9tJSSCCUqxKSxFtz5FPFUiqHSHvr2hvwp+bfNXV9Dhb4ua6Yiw+90jOmenq0WUtzlz6NrQZ2VBgG3mZ66IvAdb+eYzkiUeAzzj3AUlhDg6IuzUuvA9fmEmB18YokKUzU+3qTreBa7hqBTPjawV9E0AcZz1VwU1oDDcYCtpFkFb6SBbd/Fe7ljeEjNmAznCwzY7lBze6iK0FatzkUA3QEUqZGauPEXTuJvqLu5X6Miyy40LQczBKBn+w/kK/uFG93EdU5KoPVnLNBA== 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=Uy85KLN4YCF8T4zztIOL9b88RzLJPtyN1hm6xdOQ8ug=; b=D1sYpE+F4vr7zYUTd+eD2yqtwsWooVmUareBwX+kg/MDpP3rxTWIITG4UaU4r0dJY8ABURzIkPOwodDAD4Xs6B/9AmIbBSBzL4wK0TdOWBOC1yNPXAcTecs/ngoBstiAPqk2sin0J+IMiQE15VCNRfVYz1XB0PHul+rmwGV2r/1etBgLTha5TFadE/CQBsEhI6IzwzKwopUqdZEWUJUjeWqWmeaflXmrk4NJSgqNEL54+l7sHUHkSm1QQg2jO+iKh33fHA86pzluWLCVFE3Vyxh4JME8wBdfGPfiCubq2sq5pM49ArCWa2dH+rXwrg8FxOY5KZDwFcPFkSANsIHFog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uy85KLN4YCF8T4zztIOL9b88RzLJPtyN1hm6xdOQ8ug=; b=Ob2SctP1mTiqQt8RcAXyPz/lTUXvfIRHQmIaCnSNRE7GhOqBcMEtRqICS/841841x+qe7OpbGyYkcorZIlHKY8z0Xp0blPiLFhhcG/cLj9PvlU6Mg+HPdPjyhEc3WS52PbP+QM4Gay0826eoUN/UpEwq7ju4+BwcYZOd0vovelc= Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0567.EURP190.PROD.OUTLOOK.COM (10.175.241.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Thu, 2 Jan 2020 18:37:07 +0000 Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946%6]) with mapi id 15.20.2581.014; Thu, 2 Jan 2020 18:37:07 +0000 Received: from localhost (212.201.44.247) by FRYP281CA0008.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12 via Frontend Transport; Thu, 2 Jan 2020 18:37:06 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Jonathan CC: "netmod@ietf.org" Thread-Topic: [netmod] Clarifications re RFC 8342 NMDA Thread-Index: AQHVwY/fy7SITk65WEysD0s2tUsgKqfXtCOA Date: Thu, 2 Jan 2020 18:37:06 +0000 Message-ID: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> References: In-Reply-To: Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: FRYP281CA0008.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::18) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.201.44.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8850c76e-d8cc-4e43-8577-08d78fb2c4b3 x-ms-traffictypediagnostic: DB6P190MB0567: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(39840400004)(136003)(189003)(199004)(64756008)(66556008)(6486002)(6916009)(956004)(186003)(66446008)(16526019)(71200400001)(66946007)(66476007)(26005)(478600001)(1076003)(8676002)(86362001)(786003)(6496006)(5660300002)(8936002)(3450700001)(316002)(81166006)(4326008)(81156014)(52116002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0567; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vPU+ZrVrO4UoijAekeCZd2ow7UzTf+wyp7qyBNLg1j284xbyDbgKBhMVo52iybSCDF4AgKzwXKXV+K56x3Wpu1USe0QogCoHuV2q0JQp4VPO9NmJyOGyFzoErzEIfeXv2FuJOTYXXphdaFSXrXJLejrXmTVQpbJyjB/hjEcAWWkiL+X5IImU+Hm7C7Ega9tK8rZ4ArvXvgDslqP7f8yJP1eKCrZ4RTFR8e1SZuSZsJZfw1Y+I/rk1vdFm43cQITQS69fIrMtELqBJc0nTkFGLMBaHHqEgx6+i9cIbXfW8ZNgM2V6yHvv8QA25d41Q6NzMHLQJYu1pQt+NXNvMH0mF4sWEXtNioCf5zPRlJQ6i7AggjzCFwo3I13X/oEjR84X0yKS1OzKupYYF1uzKg+pZIuyo9HT8tmsNOJYSMj/0Tc4UQdbLs0HELuG1A1XbGUeREYLJh6usVDLjIDeo/jiKMCd/an/j9EDh4dVAr60HCA= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 8850c76e-d8cc-4e43-8577-08d78fb2c4b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 18:37:07.3408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OyQaCnbkF+rOBulRrzIvNssgP/Tjq8bNFCRxw+Z0ushUOROc9SulIckyZexaGXUp/TlCQPRVxVyqoXMpp16rrMiA7oWA+kAd81A+89ABeg8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0567 Archived-At: Subject: Re: [netmod] Clarifications re RFC 8342 NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 18:37:14 -0000 On Thu, Jan 02, 2020 at 05:12:30PM +0000, Jonathan wrote: > Hi, >=20 > I have been reading through RFC 8342 and have a number of questions I > couldn't resolve after a couple of passes through. Can anyone advise? > The RFC states "The startup configuration datastore may not be supported = by > all protocols or implementations", "the candidate configuration datastore > may not be supported by all protocols or implementations" and " > MUST be supported if the device can be configured via conventional > configuration datastores". I can find no explicit guidance on:The intende= d > configuration datastore: The RFC does state, "Whenever data is written to > , the server MUST also immediately update and validate ." > Is mandatory for NMDA-supporting servers that support > ? It is not mandatory to expose . On simple implementations, may be identical with . > The operational state datastore: The RFC does state it is "a > read-only datastore that consists of all "config true" and "config false" > nodes defined in the datastore's schema" and that "the datastore schema f= or > MUST be a superset of the combined datastore schema used in > all configuration datastores ...". Is mandatory for > NMDA-supporting servers? Since is the only way to expose config false nodes for an NMDA server, it is kind of mandatory as soon as you have config false nodes to expose. > RFC 8525, section 1 states, "For backwards > compatibility, an NMDA-supporting server SHOULD populate the deprecated > "/modules-state" tree in a backwards-compatible manner."That suggests an > NMDA-supporting server SHOULD be backwards-compatible with a > non-NMDA-supporting client. Is that correct? This might be a misuse of 'SHOULD' since backwards-compatibility is important for a transition phase but not in pure NMDA environments. The idea here was to encourage support for a transition phase where NMDA and non-NMDA implementations may need to co-exist. > Can an MMDA-supporting client be > backwards-compatible with a non-NMDA-supporting server? An NMDA client should talk NMDA with an NMDA server. Whether an NMDA client also talks to non-NMDA servers is up to the implementor. I personally would distinguish between the protocol interaction and the data model of the management application. To me, it makes a lot of sense to make the data model of the management application NMDA aware even if the application is used with non-NMDA servers. > I can't find any > mention of YANG version 1 in RFC 8342. Is it safe to assume NMDA is > compatible with YANG version 1 modules? It should not matter whether the model is written in YANG 1 or 1.1. However, core data models are moving towards YANG 1.1. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 3 01:12:35 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001F91200D8 for ; Fri, 3 Jan 2020 01:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 o3F7FzH_hZXa for ; Fri, 3 Jan 2020 01:12:33 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10058.outbound.protection.outlook.com [40.107.1.58]) (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 73B24120044 for ; Fri, 3 Jan 2020 01:12:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZmBkA3gZ8X/aNtv+rlXeSSdF2He439kxxc8bhes1TY9qPio0RUvtyZvRW0vsWLr+mbR2q1ArYLZk9B6mUt6GSJWUj9VUrOFr1fQfYZw7WNeXkTQEg0BaNqXVg8DqX+dVVKpu8qOMCS0dj6l4jpogi7/lt5b1uJY9Of740Lk5n9wLg+ZvgaI8bQGL/ORAGk79jUYc5IZhx422nqdh+JXJVHrazt7Vk4bYD1muHPeaFmyU9AaeTMqugItyxEr7Zny9WjD8/rwVdDHv50TyU2/x1SpTDJZL8vXzjFuxfOGARd0n7CxtJALo5qJ4YiBDPUpqR9LQk1OKvKAyA74VimmgYA== 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=sztfwSjB61OHYGOpnTL7yoLvWfmuAsYFQol0b1FjSWA=; b=NsuZagJRdWhir28XVzQNAGYCP/VCz0BHXP7KuJq9lKJJNaczYo2xTJVkh8/OHmAlDV0UpQaxOAZJ51JApS6n2LedVnkoZs03W005an70gLY0BZ1FWlcya0ruiAC1vjK4qxd7MdAkqHM81m5l/O9oDdXnAD33I2KedYxe7yp2KVBARdRk707eO9IZnrZNyIxNJOdjSqYYCttueN4mxtCmU3tYOSVXHyyZsuPsURCzD18bOx6wQ3sF6fcT0ry52aJpNL/IP2fGE9QZZM6pTLyT0KAHpeVMCMk4MYAcs2BJ8oR+CAgg5KtNTAYXpMJ35UDbnHUJQR2jdOC0uPzTcJOUrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sztfwSjB61OHYGOpnTL7yoLvWfmuAsYFQol0b1FjSWA=; b=qv83W7R7FI9yBkaY4eIa22v9MT8NdVhDp9EO85D/JCMAag83yRqEv19OZNwuMVldGzLXbJujGMWpIuavmKxgncHgEsSvb0xF9UqZn7P7aZXxxaJOBRGTX2Q+jsXPJSjhyeATl8VHJEbAHjzQS/28emmi12Au9fQl01HuhwYGSmY= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB5920.eurprd07.prod.outlook.com (20.178.15.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.8; Fri, 3 Jan 2020 09:12:29 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2602.012; Fri, 3 Jan 2020 09:12:29 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Ladislav Lhotka CC: NetMod WG Thread-Topic: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented Thread-Index: AdW1rIivNNF/ygLlRsqN7vYQ6ujj8wAHQSMAABzp24AAAQTrAAARCBUAAADIkQAC4vIRcA== Date: Fri, 3 Jan 2020 09:12:29 +0000 Message-ID: References: <87fthgye1c.fsf@nic.cz> <20191219075237.44xz6d34mn2ihjw2@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5a1a519-f4be-4e04-3650-08d7902d0f1d x-ms-traffictypediagnostic: VI1PR07MB5920: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0271483E06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(366004)(376002)(396003)(189003)(199004)(8936002)(66476007)(8676002)(33656002)(81156014)(81166006)(7696005)(4001150100001)(26005)(966005)(85182001)(86362001)(66446008)(64756008)(66616009)(186003)(66946007)(66556008)(76116006)(71200400001)(4326008)(53546011)(6506007)(55016002)(52536014)(5660300002)(9686003)(2906002)(316002)(110136005)(66574012)(85202003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5920; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8FPgFJ43uyHX2+TKPybfntDECXHSc6XhsZTZvyYtfce0pFnOGOmoOy4isfy33XBUABdueJb7h1f5Xz7V2/ULZA+ElM6mJSsNTgxacoWqrb2vfaKWO8tvdrAZtFxq/LqNexIRZahcMDAXDmhvHkyXb0OfkAvVxznhDHBeYynAHp7ruwKisqVexB0YxTmL3un/qJMGD8UZatfRHMmrjuMdEM9l4pR5ZO4Sih/sBiBgi2jKKZjfh2Cw2PrmA5kn10pyGoHjEzcN/ZmeAM3FwVK3vDRXnHBrMDAvlKkV3cJ+LuwHVcY65eep2yJEOOinb63kSL68t3XaiXWjtMtdwSH8tOVsK5hF96YUCpun838hgAprDzY8twNP9UnnT+ctOhQR1q+3YAVHgAd+jW9z2TTiNezF2Cy/96R4MqbF4K8q8zmN8ehzrX3suEqtKmfYoLTd+hbST7fpF8S32qjNRDLE5Tt4KTKa3H6vZBr8SHvrVS4= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01D5C21E.49EFFE10" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5a1a519-f4be-4e04-3650-08d7902d0f1d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2020 09:12:29.6266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wuhFnia0Z0cBkoQqhA94RDq+yKVgjP9tKyGjgVodd2QKaUV8clDJvfs7pX1bWtWkgM3saGhBqdtNH7ibSG0SbED5Xn4jEjWWZ6Xgc3/KARA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5920 Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 09:12:35 -0000 ------=_NextPart_000_000A_01D5C21E.49EFFE10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01D5C21E.49EFFE10" ------=_NextPart_001_000B_01D5C21E.49EFFE10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As a draft author who was asked to add text about the imports IMHO * it would be easy for me to remove the description from the import. = Actually I really just want to know what is acceptable to the group, so = I can proceed * I also think that adding this text is in most cases easy and it does = not need updates later. * The rules in some cases might not be trivial. * Imported YAMs need to be implemented if * Imported parts are included in Xpath (augment, when, must, = require-instance) * Imported YAMs do not need to be implemented if only the following are = used * Types * Features * extensions * Ambiguous if * groupings are used * if the dependency is not formally defined by YANG, but functionally = needed. (E.g. notification-capabilities does not formally need YANG-Push = to be implemented, however there is no sense in defining capabilities if = YANG-Push is itself not implemented.) * deviation ? * other cases ? Regards Balazs =20 From: netmod On Behalf Of Andy Bierman Sent: 2019. december 19., cs=C3=BCt=C3=B6rt=C3=B6k 17:23 To: Ladislav Lhotka Cc: NetMod WG Subject: Re: [netmod] Text in import to indicate whether a module is = needed as import-only or as implemented =20 =20 =20 On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > wrote: On Thu, 2019-12-19 at 07:52 +0000, Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen = wrote: > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote: > > I don't see how YANG syntax defines this. If a module imports = ietf-netconf- > > acm, it could be because > >=20 > > - it just uses a typedef, such as "node-instance-identifier", and = then > > ietf-netconf-acm needn't be implemented (but can be), > >=20 > > or > >=20 > > - it augments ietf-netconf-acm, which makes sense only if the latter > > module is implemented. > >=20 > > It it the YANG library that specifies whether a module is = implemented or > > not, but the "import" statement itself doesn't tell you anything. > >=20 >=20 > Can we not assume that an implementor will figure out the difference? An implementor should be able to figure it out, but other potential = module users may not. For example, if somebody is evaluating whether to use a module = for their device or not, it is important to know that NACM has to be = implemented (or not). =20 You seem to be talking about a new conformance documentation procedure that attempts to solve the problem "to use modules A, B, and C together to achieve some functionality X, all these conditions need to be met". (Sounds more like a problem for YANG Packages to solve) =20 IMO this is a much harder problem than something that can be solved with extra description-stmt text. The writer is likely to get it wrong = or not keep it up to date, so a tool to analyze the file seems like a better = solution. =20 Lada =20 =20 Andy =20 > Or someone writes a pyang plugin to determine from the schema tree the > kind of imports there are (for a given set of features). >=20 > /js >=20 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_001_000B_01D5C21E.49EFFE10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    As a draft = author who was asked to add text about the imports = IMHO

    • it would be easy for me to remove the description from the import. = Actually I really just want to know what is acceptable to the group, so = I can proceed
    • I also think that = adding this text is in most cases easy and it does not need updates = later.
    • The rules in some = cases might not be trivial.
      • Imported YAMs need to = be implemented if
        • Imported parts are = included in Xpath (augment, when, must, = require-instance)
      • Imported YAMs do not = need to be implemented if only the following are used
        • Types
        • Features
        • extensions
      • Ambiguous = if
        • groupings are used
        • if the dependency is = not formally defined by YANG, but functionally needed. (E.g. = notification-capabilities does not formally need YANG-Push to be = implemented, however there is no sense in defining capabilities if = YANG-Push is itself not implemented.)
        • deviation ?
        • other cases = ?

    Regards = Balazs

     

    From: netmod <netmod-bounces@ietf.org> = On Behalf Of Andy Bierman
    Sent: 2019. december 19., = cs=C3=BCt=C3=B6rt=C3=B6k 17:23
    To: Ladislav Lhotka = <lhotka@nic.cz>
    Cc: NetMod WG = <netmod@ietf.org>
    Subject: Re: [netmod] Text in import = to indicate whether a module is needed as import-only or as = implemented

     

     

     

    On = Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka <lhotka@nic.cz> = wrote:

    On Thu, 2019-12-19 at 07:52 +0000, = Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen wrote:
    > On Thu, Dec 19, 2019 = at 08:23:27AM +0100, Ladislav Lhotka wrote:
    > > I don't see how = YANG syntax defines this. If a module imports ietf-netconf-
    > > = acm, it could be because
    > >
    > > - it just uses a = typedef, such as "node-instance-identifier", and then
    > = >   ietf-netconf-acm needn't be implemented (but can = be),
    > >
    > > or
    > >
    > > - it = augments ietf-netconf-acm, which makes sense only if the latter
    > = >   module is implemented.
    > >
    > > It it = the YANG library that specifies whether a module is implemented = or
    > > not, but the "import" statement itself doesn't = tell you anything.
    > >
    >
    > Can we not assume that = an implementor will figure out the difference?

    An implementor = should be able to figure it out, but other potential module users
    may = not. For example, if somebody is evaluating whether to use a module = for
    their device or not, it is important to know that NACM has to be = implemented (or
    not).

     

    You seem to be talking about a new conformance = documentation procedure

    that attempts to solve the problem "to use = modules A, B, and C together

    to achieve some functionality X, all these conditions = need to be met".

    (Sounds more like a problem for YANG Packages to = solve)

     

    IMO this is a much harder problem than something that = can be solved

    with extra = description-stmt text. The writer is likely to get it wrong or = not

    keep it up to date, so = a tool to analyze the file seems like a better = solution.

     

    Lada

     

     

    Andy

     


    > = Or someone writes a pyang plugin to determine from the schema tree = the
    > kind of imports there are (for a given set of = features).
    >
    > /js
    >
    --
    Ladislav = Lhotka
    Head, CZ.NIC Labs
    PGP Key ID: = 0xB8F92B08A9F76C67

    _______________________________________________=
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod

    ------=_NextPart_001_000B_01D5C21E.49EFFE10-- ------=_NextPart_000_000A_01D5C21E.49EFFE10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDEwMzA5MTIyMlowIwYJKoZIhvcNAQkEMRYEFE028w9p3U6vz4cRbBz7eJXLskkhMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQAjtDBOc/BPaGIOYAWznSJftlfzLTsWIWUlIyPVRmxqBMJhBp52AIVX eIKDDBoBIMTt93H3SqPDy78Me4ne3wMb8y+NiaLKc3qUsdsJLQGJ55abrkWjV/C2RMipM5mxTIVY XxlQIHUUaeABSFSYWeyVZVrvcSHO5vA3WQ1GxIYAxoK5eyHPVtoIdD6p21bow1ZvS1BfiQvFWXJK ka7icNJUjLbIIdY7ArM07zjQXMLwJVGYg2MUodljccdHvMR+zr4XzJynaT+QPl3E5FMnigJucKZd jyw0xfz3WOqQRGSNlwkVoFvjAGyuoKPDpTytGGzfFV49h0cSuYisFWAaaVSgAAAAAAAA ------=_NextPart_000_000A_01D5C21E.49EFFE10-- From nobody Fri Jan 3 03:39:45 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC801200D7 for ; Fri, 3 Jan 2020 03:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tpFBTYuKYcxX for ; Fri, 3 Jan 2020 03:39:41 -0800 (PST) Received: from brown.birch.relay.mailchannels.net (brown.birch.relay.mailchannels.net [23.83.209.23]) (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 1166F12001E for ; Fri, 3 Jan 2020 03:39:40 -0800 (PST) X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2943B6A138C; Fri, 3 Jan 2020 11:39:40 +0000 (UTC) Received: from mail.myfast.site (100-96-83-39.trex.outbound.svc.cluster.local [100.96.83.39]) (Authenticated sender: dxszz3qpvg) by relay.mailchannels.net (Postfix) with ESMTPA id DC9886A1FBF; Fri, 3 Jan 2020 11:39:38 +0000 (UTC) X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net Received: from mail.myfast.site ([TEMPUNAVAIL]. [81.19.215.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Fri, 03 Jan 2020 11:39:40 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dxszz3qpvg|x-authuser|jonathan@hansfords.net X-MailChannels-Auth-Id: dxszz3qpvg X-Snatch-Company: 34de0e9d37ad22e3_1578051579879_3257780994 X-MC-Loop-Signature: 1578051579879:968903129 X-MC-Ingress-Time: 1578051579879 Received: from hansfords.plus.com ([84.92.116.209]:62587 helo=[192.168.54.20]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1inLIh-0002Ul-Oz; Fri, 03 Jan 2020 11:39:31 +0000 From: Jonathan To: =?utf-8?q?Sch=c3=b6nw=c3=a4lder=2c=20J=c3=bcrgen?= Cc: "netmod@ietf.org" Date: Fri, 03 Jan 2020 11:39:31 +0000 Message-Id: In-Reply-To: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> References: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> Reply-To: Jonathan User-Agent: eM_Client/7.2.36908.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBAC69995C-EC25-4881-A6B6-0C22599248EA" X-Antivirus: Avast (VPS 200102-0, 02/01/2020), Outbound message X-Antivirus-Status: Clean X-AuthUser: jonathan@hansfords.net Archived-At: Subject: Re: [netmod] Clarifications re RFC 8342 NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 11:39:43 -0000 --------=_MBAC69995C-EC25-4881-A6B6-0C22599248EA Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable ------ Original Message ------ From: "Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen" To: "Jonathan" Cc: "netmod@ietf.org" Sent: 02/01/2020 18:37:06 Subject: Re: [netmod] Clarifications re RFC 8342 NMDA >On Thu, Jan 02, 2020 at 05:12:30PM +0000, Jonathan wrote: >> Hi, >> >> I have been reading through RFC 8342 and have a number of questions I >> couldn't resolve after a couple of passes through. Can anyone advise? >> The RFC states "The startup configuration datastore may not be supporte= d by >> all protocols or implementations", "the candidate configuration datasto= re >> may not be supported by all protocols or implementations" and " >> MUST be supported if the device can be configured via conventional >> configuration datastores". I can find no explicit guidance on:The inten= ded >> configuration datastore: The RFC does state, "Whenever data is written= to >> , the server MUST also immediately update and validate ." >> Is mandatory for NMDA-supporting servers that support >> ? > >It is not mandatory to expose . On simple implementations, > may be identical with . > >> The operational state datastore: The RFC does state it is "a >> read-only datastore that consists of all "config true" and "config fals= e" >> nodes defined in the datastore's schema" and that "the datastore schema = for >> MUST be a superset of the combined datastore schema used= in >> all configuration datastores ...". Is mandatory for >> NMDA-supporting servers? > >Since is the only way to expose config false nodes for >an NMDA server, it is kind of mandatory as soon as you have config >false nodes to expose. RFC 6241 describes as retrieving "running configuration and device=20 state information" and as retrieving "all or part of a=20 specified configuration datastore". RFC 8526 introduces which=20 it describes as "similar to NETCONF's operation". As far as=20 I can tell, neither RFC 8342 not RFC 8526 actually identify which=20 operation to use to retrieve operational state data. Am I right in=20 assuming it would be ? In that case, it is similar to =20 when performed on as it will also return state data. And what should be the result of performing on an NMDA-supporting=20 server? Should it still return config true nodes from plus=20 config false nodes from ? Or should the operation be=20 rejected? > > >> RFC 8525, section 1 states, "For backwards >> compatibility, an NMDA-supporting server SHOULD populate the deprecated >> "/modules-state" tree in a backwards-compatible manner."That suggests a= n >> NMDA-supporting server SHOULD be backwards-compatible with a >> non-NMDA-supporting client. Is that correct? > >This might be a misuse of 'SHOULD' since backwards-compatibility is >important for a transition phase but not in pure NMDA environments. >The idea here was to encourage support for a transition phase where >NMDA and non-NMDA implementations may need to co-exist. > >> Can an MMDA-supporting client be >> backwards-compatible with a non-NMDA-supporting server? > >An NMDA client should talk NMDA with an NMDA server. Whether an NMDA >client also talks to non-NMDA servers is up to the implementor. I >personally would distinguish between the protocol interaction and the >data model of the management application. To me, it makes a lot of >sense to make the data model of the management application NMDA aware >even if the application is used with non-NMDA servers. > >> I can't find any >> mention of YANG version 1 in RFC 8342. Is it safe to assume NMDA is >> compatible with YANG version 1 modules? > >It should not matter whether the model is written in YANG 1 or 1.1. >However, core data models are moving towards YANG 1.1. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 --------=_MBAC69995C-EC25-4881-A6B6-0C22599248EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    ------ Original Message -= -----
    From: "Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen" <J.Schoenwaelder@jacobs-university.de&g= t;
    To: "Jonathan" <jonathan@= hansfords.net>
    Sent: 02/01/2020 18:37:06
    Subject: Re: [netmod] Clarifications re RFC 8342 NMDA

    =
    On Thu, Jan 02, 2020 at 05:12:30PM +0000, Jonatha= n wrote:
    Hi,
    =C2=A0
    I have been reading through RFC 8342 and have a= number of questions I
    couldn't resolve after a couple of passes throug= h. Can anyone advise?
    The RFC states "The startup configuration datast= ore may not be supported by
    all protocols or implementations", "the candidat= e configuration datastore
    may not be supported by all protocols or impleme= ntations" and "<running>
    MUST be supported if the device can be configure= d via conventional
    configuration datastores". I can find no explici= t guidance on:The intended
    configuration datastore: The RFC does state, "Wh= enever data is written to
    <running>, the server MUST also immediatel= y update and validate <intended>."
    Is <intended> mandatory for NMDA-supportin= g servers that support
    <running>?
    =C2=A0
    It is not mandatory to expose <intended>. O= n simple implementations,
    <intended> may be identical with <runnin= g>.
    =C2=A0
    The operational state datastore: The RFC does st= ate it is "a
    read-only datastore that consists of all "config = true" and "config false"
    nodes defined in the datastore's schema" and tha= t "the datastore schema for
    <operational> MUST be a superset of the co= mbined datastore schema used in
    all configuration datastores ...". Is <operat= ional> mandatory for
    NMDA-supporting servers?
    =C2=A0
    Since <operational> is the only way to expo= se config false nodes for
    an NMDA server, it is kind of mandatory as soon a= s you have config
    false nodes to expose.
    RFC 6241 describes <get> as retrieving = "running configuration and device state information" and <get-co= nfig> as retrieving "all or part of a s= pecified configuration=C2=A0datasto= re". RFC 8526 introduces <get-da= ta> which it describes as "simil= ar to NETCONF's <get-config>=C2=A0operation". As far as I can tell, neither RFC 8342 not RFC 8526 actual= ly identify which operation to use to retrieve operational state data. Am I = right in assuming it would be <get-config>? In that case, it is similar to <get> when performed o= n <operational> as it will also return state data.

    And what should be the result of performing &l= t;get> on an NMDA-supporting server? Should it still return config true= nodes from <running> plus config false nodes from <operational>= ? Or should the operation be rejected?


    =C2=A0
    RFC 8525, section 1 states, "For backwards
    compatibility, an NMDA-supporting server SHOULD= populate the deprecated
    "/modules-state" tree in a backwards-compatible= manner."That suggests an
    NMDA-supporting server SHOULD be backwards-compa= tible with a
    non-NMDA-supporting client. Is that correct?
    =C2=A0
    This might be a misuse of 'SHOULD' since backward= s-compatibility is
    important for a transition phase but not in pure= NMDA environments.
    The idea here was to encourage support for a tran= sition phase where
    NMDA and non-NMDA implementations may need to co-= exist.
    =C2=A0
    Can an MMDA-supporting client be
    backwards-compatible with a non-NMDA-supporting= server?
    =C2=A0
    An NMDA client should talk NMDA with an NMDA serv= er. Whether an NMDA
    client also talks to non-NMDA servers is up to th= e implementor. I
    personally would distinguish between the protocol = interaction and the
    data model of the management application. To me,= it makes a lot of
    sense to make the data model of the management ap= plication NMDA aware
    even if the application is used with non-NMDA ser= vers.
    =C2=A0
    I can't find any
    mention of YANG version 1 in RFC 8342. Is it saf= e to assume NMDA is
    compatible with YANG version 1 modules?
    =C2=A0
    It should not matter whether the model is written = in YANG 1 or 1.1.
    However, core data models are moving towards YANG = 1.1.
    =C2=A0
    /js
    =C2=A0
    --
    Juergen Schoenwaelder Jacobs University = Bremen gGmbH
    Phone: +49 421 200 3587 Campus Ring 1 | 2= 8759 Bremen | Germany
    Fax: +49 421 200 3103 <https://www.jacobs-university.de/><= /div>
    --------=_MBAC69995C-EC25-4881-A6B6-0C22599248EA-- From nobody Fri Jan 3 07:43:38 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C3120018 for ; Fri, 3 Jan 2020 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 K3FLf7RzDpSN for ; Fri, 3 Jan 2020 07:43:34 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10047.outbound.protection.outlook.com [40.107.1.47]) (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 E2A2A12000F for ; Fri, 3 Jan 2020 07:43:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nWY6aVXhKMT5EYLPgEEdU8C3pCMc/SQtLlXHPWmNg/BwHo/KQnLJVWTkBvBcWbkX0H3F3nwqZMLdLHbhRospl0FIO+tliAUjeCOIZspa/mwQIm+0nKVHunQXUf0XJtZ2NuxwAlPKRRPAmJR8WZ9WSMFDyI0Opwq+k4nNXyBNw7OYlJEHxL1zI+CNKyI09ygzMG/Ma8cAvLS14FY5LXjIl3e7CW/iiJUu1xosoHL6LMpaMmnQf7I9ZKpT/+UO9Ohq3OgmbU/g1N6SlpWLYQY1eSXD3tnPqGaFvHS7VG0n2VnKo2ZuQaAHhHd1IjknULMJKQ7XRy+W6GzsjbkhxVXDIA== 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=l5YIXvsgGIycYUYq/36SWpRF5JlGq//QgRDd2vgnHKA=; b=Cpu41wPWd4kaPjmh3kyC8TDcRYkp2eYuX6uJSAnHexZzdJmOXKeobvHI4B8DP4oOXrGF/wVftWhZ2yeQtRjFwCiZIwtI8Hs+Jo1dj/WzK0TFle73pHungwHE6FNcU4bO6cyNy7Op6Gqxzy+3CGnVuEoESxX205IyCcpg75LRYeIcoql9Tvc15u8P5MaG5CFi1KAC05t5OUEMNKmjEUbKx0dNPnhXfgLbhRe47rzp6oBiSzNj5/PpNArr7QYTSr0R9HeuTEtNPeAdUGf56p5ANfk1N18pEqyjp7vD750Y+aF1Iqj1ZS9UGCL/qh2AzT1wMSImb45/ScZyWOwK4KSoPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l5YIXvsgGIycYUYq/36SWpRF5JlGq//QgRDd2vgnHKA=; b=dHLinzaTv+H5lmdC2qrXwYLXervl+dYJV/QLATdheO1e2LD02GJoh3o2mcpRlLZZ5haZ9/SiWIi0ZrBmOwCamdwLCgHG6rNam78YiyYQx8VvKIVKBDtjv5lF9qnEZHtwy2i2gnDMwFFxhXdahXDGiIUsSSgowij6TIZprOaGPMI= Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0104.EURP190.PROD.OUTLOOK.COM (10.172.228.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Fri, 3 Jan 2020 15:43:31 +0000 Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946%6]) with mapi id 15.20.2602.012; Fri, 3 Jan 2020 15:43:31 +0000 Received: from localhost (212.201.44.247) by AM4PR08CA0049.eurprd08.prod.outlook.com (2603:10a6:205:2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Fri, 3 Jan 2020 15:43:30 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Jonathan CC: "netmod@ietf.org" Thread-Topic: [netmod] Clarifications re RFC 8342 NMDA Thread-Index: AQHVwkyMTmmXOjXGPEOqIu+iW35ptA== Date: Fri, 3 Jan 2020 15:43:31 +0000 Message-ID: <20200103154330.4iswclcwvfg4bqm5@anna.jacobs.jacobs-university.de> References: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> In-Reply-To: Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM4PR08CA0049.eurprd08.prod.outlook.com (2603:10a6:205:2::20) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.201.44.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 070faaac-df25-42d9-09c5-08d79063af17 x-ms-traffictypediagnostic: DB6P190MB0104: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0271483E06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(136003)(396003)(39850400004)(199004)(189003)(16526019)(26005)(3450700001)(6916009)(2906002)(6496006)(8936002)(52116002)(186003)(81166006)(81156014)(8676002)(6486002)(478600001)(71200400001)(66556008)(956004)(66476007)(66946007)(64756008)(66446008)(5660300002)(316002)(1076003)(4326008)(786003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0104; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VZ1zag9XWvstuBwp0+qt8AvsazOz+Uj0OjxK8Nz6eLVnw/F2L2qYH6HLXUg8BcnISHlXWBijUsKjM/1hWe9UYq7de/w/f5nR6txu3Dm4fDSCw6K606R5etqRVd1C1Atjqc1RVWMqLdTGbqoPAxMtLAivhFn0kQbWmYQE+PXrWqOCEbo471rVQjRf/a+/6PsAzdMmbD611/DnqavYCX2fZPyGDawGj2U5AY8bv5SfMa+tJ+t6rqgt/+gpQ8yFkXU/gV/AJHEnXRQR8NgbtXISu72vClpri3oo3zdf7R2+mfe8COX/uVS1fBMg/11FP56w8ZAJeOF1aBKaRDqiA9ncLWC0oMrtf2UAzzf1ZKO2+o1UN7JL51PkhzP63SezF6FlRBCPoHv/kHc2SHgGXnQzn4dPfDM6nErJt4++YLvU7f6Kgil/YtRQhpfOofPNHzNFWiF/xLFjBPtagwTAYG8PdmF0dGLk5zd6L5rfA0rm7Sc= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <91B19F764FA800468120019BB218AEF2@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 070faaac-df25-42d9-09c5-08d79063af17 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2020 15:43:31.3177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ioYvkOjkcx0EWCl5RQpEGK7cwVWVL/f8BWQQ4d2x1paklo21AQgIT4rC1l1IjdDwsrvGNeCpDjM8vz/V+Unfpu/kVKzhbKDOBblwN8Rhvmk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0104 Archived-At: Subject: Re: [netmod] Clarifications re RFC 8342 NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 15:43:37 -0000 On Fri, Jan 03, 2020 at 11:39:31AM +0000, Jonathan wrote: > > Since is the only way to expose config false nodes for > > an NMDA server, it is kind of mandatory as soon as you have config > > false nodes to expose. > RFC 6241 describes as retrieving "running configuration and device > state information" and as retrieving "all or part of a > specified configuration datastore". RFC 8526 introduces which = it > describes as "similar to NETCONF's operation". As far as I c= an > tell, neither RFC 8342 not RFC 8526 actually identify which operation to = use > to retrieve operational state data. Am I right in assuming it would be > ? In that case, it is similar to when performed on > as it will also return state data. There is quite some discussion of 'operational state datastore' in subsections of section 3.1.1 'The Operation' in RFC 8526. There is also an example in section 3.1.1.4. The operation returns config data, hence it won't return config false data, i.e., its not a good choice for . The reason why we have NMDA is that semantics have been found to be problematic. Hence, NMDA systems should use RFC 8526 operations ( and ) when talking to each other. > And what should be the result of performing on an NMDA-supporting > server? Should it still return config true nodes from plus conf= ig > false nodes from ? Or should the operation be rejected? A proper NMDA client should never send a . Supporting only makes sense for legacy clients and they might expect RFC 6241 behaviour as far as that is implementable (the reason we have NMDA is that semantics assume that is identical to config, which is just not always true). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 3 08:06:17 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68985120863 for ; Fri, 3 Jan 2020 08:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 qx64H72PlO4I for ; Fri, 3 Jan 2020 08:06:08 -0800 (PST) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3A4120846 for ; Fri, 3 Jan 2020 08:06:08 -0800 (PST) Received: by mail-lf1-x142.google.com with SMTP id l18so23988770lfc.1 for ; Fri, 03 Jan 2020 08:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C+f+3ykhd4gt1adAJPd4tViQ4+ux1prt4XHJ31r+f9U=; b=LofeaXaJkaqEWRUCb77WZXwikrGOZhjpq7wOWWFkWFmSERMzjukEdT4Yss7/dlcDRh qbESnjE9HzN2VjNoUIis1lN0OUuDJZrjxV1CP+a9sKTOEohjQ5yRG4atadG0rFOZFlfR V7q+Rjm+mHtrITmDyfHJG3UmdD853SBxMhKtI023J3M3HqwCuTW3NE/m+smoTLFpof4I v3SYv5Xguu/GvxJzLyyBG+4DujeR+kYdV7w2xm1s1uW8zpg2AM5XRRc6ljIsuAN2fyZ1 rwJkGTD9PGS0E8FZofLUoiRFOzMzdwhyzkmA8Gnz0D+tqcH3GbIxLnYfM38r7TNDXHsR D6vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C+f+3ykhd4gt1adAJPd4tViQ4+ux1prt4XHJ31r+f9U=; b=J4qNkV8xXjW7AGuqRuSlMy53cBHtJ9Hq3hBwevzW6kpBQxlD9OGtyOB3WtPvJnR2dM yB+ZLv+GJrNV8dzymdZ4SOizvJHldnI8KKS8DADdKuow6wOiIhn2rN4qVDT9qnl5D3P2 kQ+tSumcwM0zjnzz8mfr/ywrfnwyS55o738EZ6n6CboWlisn9tfEj32/9G4q8GaO09fN pgZLka3jUF065XT23fikTnkFIauUnEM2a0mg2aVPoUtojVgi4NS3rWqO0fAh4fEmTz4s lSx0i7b3L07XJP4T14u7akEfsRw+x9XG/i17bK8Y4y+njDVQznxMHIx43Y8VmbbkbvbR F3dw== X-Gm-Message-State: APjAAAXudnk7TsIUrQwag4q7ZKs8dBiSNqNz3R/J8HFEGT1UcVAGzKCJ f0a3F05enGCm4kHNlxpPH900WN0aE7UXmvuC3Eo9HA== X-Google-Smtp-Source: APXvYqy5kQIbSyrGUHp0TrPL9z1IBAusLEmbgrBuEW7pCYaK/fF/eLhUrjYzxocVp5YtpKVqxFoWPpmhcp196MzfPtQ= X-Received: by 2002:a19:4b87:: with SMTP id y129mr53408964lfa.32.1578067566622; Fri, 03 Jan 2020 08:06:06 -0800 (PST) MIME-Version: 1.0 References: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> <20200103154330.4iswclcwvfg4bqm5@anna.jacobs.jacobs-university.de> In-Reply-To: <20200103154330.4iswclcwvfg4bqm5@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Fri, 3 Jan 2020 08:05:55 -0800 Message-ID: To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Cc: Jonathan , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd8ecb059b3e7cb2" Archived-At: Subject: Re: [netmod] Clarifications re RFC 8342 NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 16:06:15 -0000 --000000000000bd8ecb059b3e7cb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 3, 2020 at 7:43 AM Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen < J.Schoenwaelder@jacobs-university.de> wrote: > On Fri, Jan 03, 2020 at 11:39:31AM +0000, Jonathan wrote: > > > Since is the only way to expose config false nodes for > > > an NMDA server, it is kind of mandatory as soon as you have config > > > false nodes to expose. > > > RFC 6241 describes as retrieving "running configuration and devic= e > > state information" and as retrieving "all or part of a > > specified configuration datastore". RFC 8526 introduces whic= h > it > > describes as "similar to NETCONF's operation". As far as I > can > > tell, neither RFC 8342 not RFC 8526 actually identify which operation t= o > use > > to retrieve operational state data. Am I right in assuming it would be > > ? In that case, it is similar to when performed on > > as it will also return state data. > > There is quite some discussion of 'operational state datastore' in > subsections of section 3.1.1 'The Operation' in RFC 8526. > There is also an example in section 3.1.1.4. > > The operation returns config data, hence it won't return > config false data, i.e., its not a good choice for . The > reason why we have NMDA is that semantics have been found to be > problematic. Hence, NMDA systems should use RFC 8526 operations > ( and ) when talking to each other. > > > And what should be the result of performing on an NMDA-supporting > > server? Should it still return config true nodes from plus > config > > false nodes from ? Or should the operation be rejected? > > A proper NMDA client should never send a . Supporting only > makes sense for legacy clients and they might expect RFC 6241 > behaviour as far as that is implementable (the reason we have NMDA is > that semantics assume that is identical to > config, which is just not always true). > > This issue has been discussed quite a bit. RFC 8526 does not change RFC 6241 in any way. Period. The implementation of , , and are not changed at all if NMDA is also supported by the server. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000bd8ecb059b3e7cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Fri, Jan 3, 2020 at 7:43 AM Sch=C3= =B6nw=C3=A4lder, J=C3=BCrgen <J.Schoenwaelder@jacobs-university.de> wrote:
    =
    On Fri, Jan 03, 2020 at 1= 1:39:31AM +0000, Jonathan wrote:
    > > Since <operational> is the only way to expose config false = nodes for
    > > an NMDA server, it is kind of mandatory as soon as you have confi= g
    > > false nodes to expose.

    > RFC 6241 describes <get> as retrieving "running configurati= on and device
    > state information" and <get-config> as retrieving "all= or part of a
    > specified configuration datastore". RFC 8526 introduces <get-d= ata> which it
    > describes as "similar to NETCONF's <get-config> operati= on". As far as I can
    > tell, neither RFC 8342 not RFC 8526 actually identify which operation = to use
    > to retrieve operational state data. Am I right in assuming it would be=
    > <get-config>? In that case, it is similar to <get> when pe= rformed on
    > <operational> as it will also return state data.

    There is quite some discussion of 'operational state datastore' in<= br> subsections of section 3.1.1 'The <get-data> Operation' in RF= C 8526.
    There is also an example in section 3.1.1.4.

    The <get-config> operation returns config data, hence it won't re= turn
    config false data, i.e., its not a good choice for <operational>. The=
    reason why we have NMDA is that <get> semantics have been found to be=
    problematic. Hence, NMDA systems should use RFC 8526 operations
    (<get-data> and <edit-data>) when talking to each other.

    > And what should be the result of performing <get> on an NMDA-sup= porting
    > server? Should it still return config true nodes from <running> = plus config
    > false nodes from <operational>? Or should the operation be rejec= ted?

    A proper NMDA client should never send a <get>. Supporting <get>= ; only
    makes sense for legacy clients and they might expect RFC 6241
    behaviour as far as that is implementable (the reason we have NMDA is
    that <get> semantics assume that <running> is identical to <= applied>
    config, which is just not always true).



    This issue has been dis= cussed quite a bit.
    RFC 8526 does not change RFC 6241 in any way.= Period.
    The implementation of <get>, <get-config>, a= nd <edit-config> are
    not changed at all if NMDA is also sup= ported by the server.


    /js


    Andy
    =C2=A0
    --
    Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
    Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
    Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

    _______________________________________________
    netmod mailing list
    netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
    --000000000000bd8ecb059b3e7cb2-- From nobody Sun Jan 5 08:55:45 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBB71200EB; Sun, 5 Jan 2020 08:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 s4CRrvdd0TMH; Sun, 5 Jan 2020 08:55:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928E6120018; Sun, 5 Jan 2020 08:55:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B8B28F406F7; Sun, 5 Jan 2020 08:55:11 -0800 (PST) To: mohamed.boucadair@orange.com, dean@voltanet.io, bclaise@cisco.com, camoberg@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: warren@kumari.net, iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200105165511.B8B28F406F7@rfc-editor.org> Date: Sun, 5 Jan 2020 08:55:11 -0800 (PST) Archived-At: Subject: [netmod] [Errata Held for Document Update] RFC8199 (5924) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2020 16:55:38 -0000 The following errata report has been held for document update for RFC8199, "YANG Module Classification". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5924 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Mohamed Boucadair Date Reported: 2019-12-02 Held by: Warren Kumari (Ops AD) (IESG) Section: Section 6.1 Original Text ------------- 6.1. Normative References ... [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, . Corrected Text -------------- 6.1. Informative References ... [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, . Notes ----- RFC8049 is cited only as an example (Section 2.1): "An example of a Network Service YANG Module is in [RFC8049]..." Not sure why it was listed as normative. [Warren Kumari: Thanks to Benoit and Joel for review. ] -------------------------------------- RFC8199 (draft-ietf-netmod-yang-model-classification-08) -------------------------------------- Title : YANG Module Classification Publication Date : July 2017 Author(s) : D. Bogdanovic, B. Claise, C. Moberg Category : INFORMATIONAL Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Jan 7 02:31:23 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3098212001E for ; Tue, 7 Jan 2020 02:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1YUyZiye_QcV for ; Tue, 7 Jan 2020 02:31:19 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 36448120019 for ; Tue, 7 Jan 2020 02:31:19 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 007APBEc016995 for ; Tue, 7 Jan 2020 05:31:18 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2xc9wf68uq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 07 Jan 2020 05:31:18 -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 007AVHYd008089 for ; Tue, 7 Jan 2020 05:31:17 -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 007AVD4v008031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 7 Jan 2020 05:31:14 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id B4624400B579 for ; Tue, 7 Jan 2020 10:31:13 +0000 (GMT) Received: from gbcdcmbx15.intl.att.com (unknown [135.76.180.51]) by zlp27128.vci.att.com (Service) with ESMTPS id 69E9B400B578 for ; Tue, 7 Jan 2020 10:31:13 +0000 (GMT) Received: from gbcdcmbx15.intl.att.com (135.76.180.51) by gbcdcmbx15.intl.att.com (135.76.180.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Tue, 7 Jan 2020 10:31:11 +0000 Received: from gbcdcmbx15.intl.att.com ([fe80::f44d:965d:2bf3:fe97]) by gbcdcmbx15.intl.att.com ([fe80::f44d:965d:2bf3:fe97%5]) with mapi id 15.01.1847.003; Tue, 7 Jan 2020 10:31:10 +0000 From: "Ivory, William" To: "netmod@ietf.org" Thread-Topic: Query about must statement syntax Thread-Index: AQHVxUWUKG0nt7JeKEWqyBz0mcYP0Q== Date: Tue, 7 Jan 2020 10:31:10 +0000 Message-ID: <5dd9acc04237a6160c93da52bcbe1330834616c7.camel@intl.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 x-originating-ip: [135.76.168.250] Content-Type: multipart/alternative; boundary="_000_5dd9acc04237a6160c93da52bcbe1330834616c7camelintlattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-07_02:2020-01-06,2020-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 impostorscore=0 spamscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1031 adultscore=0 mlxscore=0 mlxlogscore=304 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001070086 Archived-At: Subject: [netmod] Query about must statement syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 10:31:21 -0000 --_000_5dd9acc04237a6160c93da52bcbe1330834616c7camelintlattcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkndmUgZ290IGEgbXVzdCBzdGF0ZW1lbnQgdGhhdCBjYXVzZXMgYSBjb21waWxhdGlv biBlcnJvciBvbiBhIENpc2NvIE5DUyBkZXZpY2UgKGFkbWl0dGVkbHkgYW5jaWVudCAoTkNTIHZl cnNpb24gMy40LjQpLCBidXQgY2FuJ3QgdXBkYXRlIGl0KSwgYXMgZm9sbG93czoNCg0KbXVzdCAi KC4uLy4uL3BhY2tldHMgKiBjdXJyZW50KCkpIDw9ICguLi8uLi9pbnRlcnZhbCAqIDEwMDApIjsN Cg0KRXJyb3IgaXMgJ2Vycm9yOiBYUGF0aCBzeW50YXggZXJyb3I6IDQwOiB1bmtub3duIG9wZXJh dG9yIGN1cnJlbnQnDQoNCkhvd2V2ZXIsIG91ciBpbnRlcm5hbCBYUEFUSCBjb21waWxlciB0aGlu a3MgdGhpcyBpcyB2YWxpZCwgYW5kIGlmIEkgY2hhbmdlIHRoZSBvcmRlciBpbiB0aGUgbXVzdCBz dGF0ZW1lbnQgdG8gdGhlIGZvbGxvd2luZywgdGhlIE5DUyBpcyBoYXBweToNCg0KbXVzdCAiKGN1 cnJlbnQoKSAqIC4uLy4uL3BhY2tldHMpIDw9ICguLi8uLi9pbnRlcnZhbCAqIDEwMDApIjsNCg0K Q2FuIGFueW9uZSBjb25maXJtIGlmIHRoZXJlIGlzIGEgZ2VudWluZSBlcnJvciBpbiB0aGUgb3Jp Z2luYWwgbXVzdCBzdGF0ZW1lbnQsIG9yIGlzIGl0IHZhbGlkIFhQQVRIPw0KDQpUaGFua3MsDQoN CldpbGxpYW0NCg== --_000_5dd9acc04237a6160c93da52bcbe1330834616c7camelintlattcom_ Content-Type: text/html; charset="utf-8" Content-ID: <97017663E33A3E4FA1616DE4B5EB06B9@intl.att.com> Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keSBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0OyBkaXJlY3Rpb246bHRyOyI+DQo8ZGl2PkhpLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+SSd2ZSBnb3QgYSBtdXN0IHN0YXRlbWVudCB0aGF0IGNhdXNl cyBhIGNvbXBpbGF0aW9uIGVycm9yIG9uIGEgQ2lzY28gTkNTIGRldmljZSAoYWRtaXR0ZWRseSBh bmNpZW50IChOQ1MgdmVyc2lvbiAzLjQuNCksIGJ1dCBjYW4ndCB1cGRhdGUgaXQpLCBhcyBmb2xs b3dzOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IHdoaXRlLXNwYWNlOiBub3Jt YWw7Ij5tdXN0ICZxdW90OyguLi8uLi9wYWNrZXRzICogY3VycmVudCgpKSAmbHQ7PSAoLi4vLi4v aW50ZXJ2YWwgKiAxMDAwKSZxdW90Ozs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsiPkVycm9yIGlzICc8L3NwYW4+ZXJyb3I6IFhQYXRoIHN5bnRheCBlcnJvcjogNDA6IHVu a25vd24gb3BlcmF0b3IgY3VycmVudCc8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkhv d2V2ZXIsIG91ciBpbnRlcm5hbCBYUEFUSCBjb21waWxlciB0aGlua3MgdGhpcyBpcyB2YWxpZCwg YW5kIGlmIEkgY2hhbmdlIHRoZSBvcmRlciBpbiB0aGUgbXVzdCBzdGF0ZW1lbnQgdG8gdGhlIGZv bGxvd2luZywgdGhlIE5DUyBpcyBoYXBweTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAs IDApOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+bXVzdCAmcXVvdDsoY3VycmVudCgpICogLi4vLi4v cGFja2V0cykgJmx0Oz0gKC4uLy4uL2ludGVydmFsICogMTAwMCkmcXVvdDs7PC9zcGFuPjwvZGl2 Pg0KPGRpdj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJn YigwLCAwLCAwKTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxk aXY+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5DYW4gYW55b25lIGNvbmZpcm0gaWYgdGhlcmUg aXMgYSBnZW51aW5lIGVycm9yIGluIHRoZSBvcmlnaW5hbCBtdXN0IHN0YXRlbWVudCwgb3IgaXMg aXQgdmFsaWQgWFBBVEg/PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5U aGFua3MsPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5XaWxsaWFtPC9z cGFuPjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5dd9acc04237a6160c93da52bcbe1330834616c7camelintlattcom_-- From nobody Tue Jan 7 03:43:19 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6241120072 for ; Tue, 7 Jan 2020 03:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cuZDjq1cEZ1K for ; Tue, 7 Jan 2020 03:43:16 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45EAE120026 for ; Tue, 7 Jan 2020 03:43:16 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5027B1AE018C; Tue, 7 Jan 2020 12:43:13 +0100 (CET) Date: Tue, 07 Jan 2020 12:42:36 +0100 (CET) Message-Id: <20200107.124236.2150818227881781740.mbj@tail-f.com> To: william.ivory@intl.att.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <5dd9acc04237a6160c93da52bcbe1330834616c7.camel@intl.att.com> References: <5dd9acc04237a6160c93da52bcbe1330834616c7.camel@intl.att.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Query about must statement syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 11:43:18 -0000 Hi, "Ivory, William" wrote: > Hi, > > I've got a must statement that causes a compilation error on a Cisco NCS device (admittedly ancient (NCS version 3.4.4), but can't update it), as follows: > > must "(../../packets * current()) <= (../../interval * 1000)"; > > Error is 'error: XPath syntax error: 40: unknown operator current' > > However, our internal XPATH compiler thinks this is valid, and if I change the order in the must statement to the following, the NCS is happy: > > must "(current() * ../../packets) <= (../../interval * 1000)"; > > Can anyone confirm if there is a genuine error in the original must > statement, or is it valid XPATH? The XPath expression is legal. /martin From nobody Tue Jan 7 03:44:36 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F250120072 for ; Tue, 7 Jan 2020 03:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Cu2y4RvKdqUR for ; Tue, 7 Jan 2020 03:44:32 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 C54C5120026 for ; Tue, 7 Jan 2020 03:44:31 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 007BZTbR006675; Tue, 7 Jan 2020 06:44:30 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2xc9wf732x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2020 06:44:30 -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 007BiTmV027316; Tue, 7 Jan 2020 06:44:30 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 007BiQUB027285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Jan 2020 06:44:26 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 20A7416A3E6; Tue, 7 Jan 2020 11:44:26 +0000 (GMT) Received: from gbcdcmbx13.intl.att.com (unknown [135.76.180.49]) by zlp27125.vci.att.com (Service) with ESMTPS id CAE2316A3E5; Tue, 7 Jan 2020 11:44:25 +0000 (GMT) Received: from gbcdcmbx15.intl.att.com (135.76.180.51) by gbcdcmbx13.intl.att.com (135.76.180.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Tue, 7 Jan 2020 11:44:23 +0000 Received: from gbcdcmbx15.intl.att.com ([fe80::f44d:965d:2bf3:fe97]) by gbcdcmbx15.intl.att.com ([fe80::f44d:965d:2bf3:fe97%5]) with mapi id 15.01.1847.003; Tue, 7 Jan 2020 11:44:23 +0000 From: "Ivory, William" To: "mbj@tail-f.com" CC: "netmod@ietf.org" Thread-Topic: [netmod] Query about must statement syntax Thread-Index: AQHVxUWU63FnkN7uP0mXcxnkdDcxHqffFJEAgAAAfwA= Date: Tue, 7 Jan 2020 11:44:23 +0000 Message-ID: References: <5dd9acc04237a6160c93da52bcbe1330834616c7.camel@intl.att.com> <20200107.124236.2150818227881781740.mbj@tail-f.com> In-Reply-To: <20200107.124236.2150818227881781740.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 x-originating-ip: [135.76.168.250] Content-Type: multipart/alternative; boundary="_000_e0e233844f1abb45c63811bb9d068ca6f44146b0camelintlattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-07_03:2020-01-06,2020-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 impostorscore=0 spamscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1015 adultscore=0 mlxscore=0 mlxlogscore=512 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001070095 Archived-At: Subject: Re: [netmod] Query about must statement syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 11:44:34 -0000 --_000_e0e233844f1abb45c63811bb9d068ca6f44146b0camelintlattcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBjb25maXJtaW5nLg0KDQpXaWxsaWFtDQoNCk9uIFR1ZSwgMjAyMC0wMS0wNyBh dCAxMjo0MiArMDEwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCg0KSGksDQoNCg0KIkl2b3J5 LCBXaWxsaWFtIiA8d2lsbGlhbS5pdm9yeUBpbnRsLmF0dC5jb208bWFpbHRvOndpbGxpYW0uaXZv cnlAaW50bC5hdHQuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQoNCkkndmUgZ290IGEgbXVzdCBzdGF0 ZW1lbnQgdGhhdCBjYXVzZXMgYSBjb21waWxhdGlvbiBlcnJvciBvbiBhIENpc2NvIE5DUyBkZXZp Y2UgKGFkbWl0dGVkbHkgYW5jaWVudCAoTkNTIHZlcnNpb24gMy40LjQpLCBidXQgY2FuJ3QgdXBk YXRlIGl0KSwgYXMgZm9sbG93czoNCg0KDQptdXN0ICIoLi4vLi4vcGFja2V0cyAqIGN1cnJlbnQo KSkgPD0gKC4uLy4uL2ludGVydmFsICogMTAwMCkiOw0KDQoNCkVycm9yIGlzICdlcnJvcjogWFBh dGggc3ludGF4IGVycm9yOiA0MDogdW5rbm93biBvcGVyYXRvciBjdXJyZW50Jw0KDQoNCkhvd2V2 ZXIsIG91ciBpbnRlcm5hbCBYUEFUSCBjb21waWxlciB0aGlua3MgdGhpcyBpcyB2YWxpZCwgYW5k IGlmIEkgY2hhbmdlIHRoZSBvcmRlciBpbiB0aGUgbXVzdCBzdGF0ZW1lbnQgdG8gdGhlIGZvbGxv d2luZywgdGhlIE5DUyBpcyBoYXBweToNCg0KDQptdXN0ICIoY3VycmVudCgpICogLi4vLi4vcGFj a2V0cykgPD0gKC4uLy4uL2ludGVydmFsICogMTAwMCkiOw0KDQoNCkNhbiBhbnlvbmUgY29uZmly bSBpZiB0aGVyZSBpcyBhIGdlbnVpbmUgZXJyb3IgaW4gdGhlIG9yaWdpbmFsIG11c3QNCg0Kc3Rh dGVtZW50LCBvciBpcyBpdCB2YWxpZCBYUEFUSD8NCg0KDQpUaGUgWFBhdGggZXhwcmVzc2lvbiBp cyBsZWdhbC4NCg0KDQoNCi9tYXJ0aW4NCg0K --_000_e0e233844f1abb45c63811bb9d068ca6f44146b0camelintlattcom_ Content-Type: text/html; charset="utf-8" Content-ID: <915A9E1554889B458EE67DD0CD3AAE21@intl.att.com> Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keSBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0OyBkaXJlY3Rpb246bHRyOyI+DQo8ZGl2PlRoYW5rcyBmb3IgY29u ZmlybWluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldpbGxpYW08L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uIFR1ZSwgMjAyMC0wMS0wNyBhdCAxMjo0MiAmIzQzOzAx MDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0OjJweCAjNzI5ZmNmIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPHByZT5IaSw8L3ByZT4NCjxwcmU+PGJyPjwvcHJlPg0KPHBy ZT4mcXVvdDtJdm9yeSwgV2lsbGlhbSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndpbGxpYW0u aXZvcnlAaW50bC5hdHQuY29tIj53aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbTwvYT4mZ3Q7IHdy b3RlOjwvcHJlPg0KPHByZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7IGJvcmRlci1sZWZ0OjJweCAjNzI5ZmNmIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi PjwvYmxvY2txdW90ZT48L3ByZT4NCjxwcmU+SGksPC9wcmU+DQo8cHJlPjxicj48L3ByZT4NCjxw cmU+SSd2ZSBnb3QgYSBtdXN0IHN0YXRlbWVudCB0aGF0IGNhdXNlcyBhIGNvbXBpbGF0aW9uIGVy cm9yIG9uIGEgQ2lzY28gTkNTIGRldmljZSAoYWRtaXR0ZWRseSBhbmNpZW50IChOQ1MgdmVyc2lv biAzLjQuNCksIGJ1dCBjYW4ndCB1cGRhdGUgaXQpLCBhcyBmb2xsb3dzOjwvcHJlPg0KPHByZT48 YnI+PC9wcmU+DQo8cHJlPm11c3QgJnF1b3Q7KC4uLy4uL3BhY2tldHMgKiBjdXJyZW50KCkpICZs dDs9ICguLi8uLi9pbnRlcnZhbCAqIDEwMDApJnF1b3Q7OzwvcHJlPg0KPHByZT48YnI+PC9wcmU+ DQo8cHJlPkVycm9yIGlzICdlcnJvcjogWFBhdGggc3ludGF4IGVycm9yOiA0MDogdW5rbm93biBv cGVyYXRvciBjdXJyZW50JzwvcHJlPg0KPHByZT48YnI+PC9wcmU+DQo8cHJlPkhvd2V2ZXIsIG91 ciBpbnRlcm5hbCBYUEFUSCBjb21waWxlciB0aGlua3MgdGhpcyBpcyB2YWxpZCwgYW5kIGlmIEkg Y2hhbmdlIHRoZSBvcmRlciBpbiB0aGUgbXVzdCBzdGF0ZW1lbnQgdG8gdGhlIGZvbGxvd2luZywg dGhlIE5DUyBpcyBoYXBweTo8L3ByZT4NCjxwcmU+PGJyPjwvcHJlPg0KPHByZT5tdXN0ICZxdW90 OyhjdXJyZW50KCkgKiAuLi8uLi9wYWNrZXRzKSAmbHQ7PSAoLi4vLi4vaW50ZXJ2YWwgKiAxMDAw KSZxdW90Ozs8L3ByZT4NCjxwcmU+PGJyPjwvcHJlPg0KPHByZT5DYW4gYW55b25lIGNvbmZpcm0g aWYgdGhlcmUgaXMgYSBnZW51aW5lIGVycm9yIGluIHRoZSBvcmlnaW5hbCBtdXN0PC9wcmU+DQo8 cHJlPnN0YXRlbWVudCwgb3IgaXMgaXQgdmFsaWQgWFBBVEg/IDwvcHJlPg0KPHByZT48L3ByZT4N CjxwcmU+PGJyPjwvcHJlPg0KPHByZT5UaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBsZWdhbC48L3By ZT4NCjxwcmU+PGJyPjwvcHJlPg0KPHByZT48YnI+PC9wcmU+DQo8cHJlPi9tYXJ0aW48L3ByZT4N CjxwcmU+PGJyPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e0e233844f1abb45c63811bb9d068ca6f44146b0camelintlattcom_-- From nobody Tue Jan 7 04:41:30 2020 Return-Path: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3129B1200C5 for ; Tue, 7 Jan 2020 04:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 EPa8Sp-JhBT7 for ; Tue, 7 Jan 2020 04:41:26 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612B9120044 for ; Tue, 7 Jan 2020 04:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1578400883; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=ivnvyxMIQZPJWYDTBQWsdHQmpruhZsaXFaXoaMrLpnE=; b=jJlMSHa2DrNEIwgjK8Mr27IfSM+r4TcP8dtFTJNVOBDd2lnnUfMC+TiBCOeQcblx EhBj2ERQY3+0mCPqL2l7LYuj1s3JuYbiEjrYwLolK84JzHn3ufrF1RyuEqoKBZ9h1Ug 4UyBKLQcwjJeCUoQB3BmxRR6vSE55xZqZHjIiVrY= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@email.amazonses.com> Date: Tue, 7 Jan 2020 12:41:23 +0000 To: NETMOD Working Group X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.07-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 12:41:28 -0000 This begins a two-week Working Group Last Call (WGLC) on = draft-ietf-netmod-yang-instance-file-format-06. The WGLC ends on Jan = 21. Please send your comments to the working group mailing list. Positive comments, e.g., "I've reviewed this document and believe it is = ready for publication", are welcome! This is useful and important, even = from authors. Objections, concerns, and suggestions are also welcomed = at this time. Thank you, NETMOD Chairs From nobody Tue Jan 7 04:45:53 2020 Return-Path: <0100016f800a15f0-e2786e5f-c870-44bf-8f2b-fbc6c863daa4-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FD01200C5 for ; Tue, 7 Jan 2020 04:45:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 qy4EYOBOY9lr for ; Tue, 7 Jan 2020 04:45:44 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21471200B6 for ; Tue, 7 Jan 2020 04:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1578401142; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=8RfctE1oRtR1R6obDLn5UOcn5K38nE1ZpvWPB4YhQ9o=; b=KjQxo9fivu/Ypgeh5CySdLnGT3Nclnex70/p0+QGjRD/eRazKl/r9GGN5kcIile1 KqN5k50b9hFfNymouNOvTh18UCATH5E9Bt8iDFrh1PjGVP0S4w8Xa6ghIlWs914c6N8 UUTlwpL3Vblb++UTjQWQX4hLIdhs9MQyUKRTRPhs= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_5643A7FE-7589-4B8F-B950-E7C4CABF46D4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016f800a15f0-e2786e5f-c870-44bf-8f2b-fbc6c863daa4-000000@email.amazonses.com> Date: Tue, 7 Jan 2020 12:45:42 +0000 Cc: NETMOD Working Group To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , Benoit Claise X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.07-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] IPR poll on draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 12:45:49 -0000 --Apple-Mail=_5643A7FE-7589-4B8F-B950-E7C4CABF46D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To each author and contributor listed on the "To" line. In order to complete the WGLC poll, are you aware of any IPR that = applies to draft-ietf-netmod-yang-instance-file-format? Please Reply-All to *this* = email and state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think = appropriate. If you are listed as a document author or contributor please answer the = above by responding to this email regardless of whether or not you are aware of = any relevant IPR. This document will not advance to the next stage until a response = has been received from each author and listed contributor. NOTE: THIS APPLIES TO = ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed = as an author or contributor, we remind you of your obligations under the IETF IPR = rules which encourages you to notify the IETF if you are aware of IPR of others on = an IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please see the RFCs = listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . NETMOD Chairs --Apple-Mail=_5643A7FE-7589-4B8F-B950-E7C4CABF46D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    To each author and = contributor listed on the "To" line.

    In = order to complete the WGLC poll, are you aware of any IPR that = applies to
    draft-ietf-netmod-yang-instance-file-format?  Please = Reply-All to *this* email
    and state = either:

    "No, I'm not aware = of any IPR that applies to this draft"
    or
    "Yes, = I'm aware of IPR that applies to this draft"

    If "yes", has this IPR been disclosed in compliance = with IETF IPR rules
    (see RFCs 3669, 5378 and 8179 for more = details)?

    If "yes" again, = please state either:

    "Yes, the IPR has = been disclosed in compliance with IETF IPR rules"
    or
    "No, = the IPR has not been disclosed"

    If you = answer no, please provide any additional details you think = appropriate.

    If you are listed as = a document author or contributor please answer the above by
    responding to this email regardless of whether or not = you are aware of any relevant
    IPR.  This document will not advance = to the next stage until a response has been
    received from each = author and listed contributor.  NOTE: THIS APPLIES TO ALL
    OF YOU = LISTED IN THIS MESSAGE'S TO LINES.

    If you are on the WG email list or attend WG meetings = but are not listed as an author
    or contributor, we remind you of your = obligations under the IETF IPR rules which
    encourages you to = notify the IETF if you are aware of IPR of others on an IETF
    contribution, or to refrain from participating in any = contribution or discussion related
    to your undisclosed = IPR. For more information, please see the RFCs listed above
    and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellec= tualProperty.

    NETMOD Chairs

    = --Apple-Mail=_5643A7FE-7589-4B8F-B950-E7C4CABF46D4-- From nobody Tue Jan 7 04:58:36 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322E61200C5 for ; Tue, 7 Jan 2020 04:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 qf0VeRKthRRT for ; Tue, 7 Jan 2020 04:58:29 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70082.outbound.protection.outlook.com [40.107.7.82]) (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 7BF10120044 for ; Tue, 7 Jan 2020 04:58:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LVTnvUQfJgsCbQipEQTicQHKd+H8dOb0dQ3YWBvcHy7bpepR9NjojdGUTt0Oq7QfZrRz7lmyiMpweFxeZUDx3ZE7pMN2DAc5SZwkJMQvjdSIcJcTq03tFDFQloWgCxLP9hnrw3WeQ3F+ynys26dk56QTRIy5C5OGBwC3mCDso14UNZyuopIUktBY/vg67V+8yXF+Ka8BQ2ZcIqHccfYpeN8ODIxIkTRum+gDzYgkvWODL0VoZVOFugdRnSN0By7KqytGw/+5u5SOEhx3K40Pfevo0B+xBG/IV/nRpIj82gOQoa7prtTu6Yj3unN9mYb1oEZyYRs707M9PHx+tBJpiQ== 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=sLJpWWMPGQ0KpBJ5InowurZaeio/yPr4V0diyTWYGs4=; b=WRt4N8LRYh067IS72wSj127gNIDR/cW5JhjIC6/1Z1XiUO/OdiHtO4qzhcDtbOPvne/q41vb8+T5cLBdvfivirz3N4cAtolEp79kyUs1auuNcVcHiRAOxis5Tm/OSZMX8nGiHzyR4w3GiXq31/KJ4N7NEi3Cqee/Zxyvh3SQG6kx/Z3Ots3Ze5DGttIXGTUroA23HBKTStS34/W5X53FTKfGXHAdLrL+ATBWCgEAgN+j3pWEWUVZTfEXy58qQKXVGOY4w0jZKxC2UQBVZ+1yF06bUpluwzgQB9WCHbLkTvuOgZi777HqLvmVAf8Sjyt9/MLNLF8GdfREJgkII8wD9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sLJpWWMPGQ0KpBJ5InowurZaeio/yPr4V0diyTWYGs4=; b=WYVEZAurDxmYGmL2HpWT760olyedqXEU7yk5anXxFc9y5uYmkfw5+L2Senf/TExEIwHcSXmIMTXN4W5LyayxSMMZ6oTNtX4tK66ck239Qxdfd3ZZ/axr9DQQzdk/wwTZUnXHmgA6jJLfuVi3FXWQSubDTiEltmuV+h0COQgh+LM= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB6111.eurprd07.prod.outlook.com (20.178.124.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.6; Tue, 7 Jan 2020 12:58:25 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2623.008; Tue, 7 Jan 2020 12:58:25 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , Benoit Claise CC: NETMOD Working Group Thread-Topic: IPR poll on draft-ietf-netmod-yang-instance-file-format Thread-Index: AQHVxVhkA7vVSWmzvkOMeYJL42YxMaffKWQg Date: Tue, 7 Jan 2020 12:58:25 +0000 Message-ID: References: <0100016f800a15f0-e2786e5f-c870-44bf-8f2b-fbc6c863daa4-000000@email.amazonses.com> In-Reply-To: <0100016f800a15f0-e2786e5f-c870-44bf-8f2b-fbc6c863daa4-000000@email.amazonses.com> 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=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c13e512-5877-4da3-c50f-08d7937148af x-ms-traffictypediagnostic: VI1PR07MB6111: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(376002)(346002)(189003)(199004)(8676002)(81166006)(71200400001)(316002)(5660300002)(8936002)(66574012)(81156014)(86362001)(2906002)(52536014)(6506007)(33656002)(966005)(186003)(53546011)(4326008)(55016002)(26005)(9686003)(66476007)(66946007)(66446008)(7696005)(64756008)(110136005)(76116006)(478600001)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6111; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 80oSe907e1uEVTSmIavNjn8538zKpMkEqQRAYXs0s3ADhDkR2J/C+DMkPrTCUDVpnYUFFvadN/ojUS7DhijVUsgJy3/4UxraQ5rLekyQgp+E3Y41R8gFL8W3fILXrUnprhTyjE85IyVfYTjgI+cm2iS3Jj9E69Lbd2fxZWUk4CgTCuzpaZQhNZ2ige2GQFJwHClECU8SYCOsU5hPFzz/DdddV0DCtW0mxXjr8wHkGZ2TI44KwVYfBmqIzPqAPzdhFhEgQ83wM9ZwRkfgY5SdeuypyG2dHcFm7wIu1I3IqkOSE3xv5385fnYNsRbHUNiMw6Pn0sBQCn0HpzEu0d6z4wb3EF4ESbBbYUxNfEww02h18B9dlMHtaTUTj6RO/iDKcQmwgyIwhTX244cAa/UO2kgtEwCQBj2+4ajPmeJXqBMt0aHrGHMzLHGGtppkaJtiae8KiXA+xOxy8DUnpTHgDVMXPgqUb+eX0uc/ywXUV8e1ZSBs1Yq7BKLjbdB0NLIhCz6orVHoCsn+EnxL5xhvyA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR07MB404725309C259F90845899C2F03F0VI1PR07MB4047eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c13e512-5877-4da3-c50f-08d7937148af X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 12:58:25.4761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ge3rzgBNGzJOwmfcZ5L3PAom6dbzeckk4WWDIWLkM4gAjzgRE+QIBVUJY6esYWij/hxx0B9L027t/ZVKRWgttZDX8Zfkc/2SwyP1dkI8qJ4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6111 Archived-At: Subject: Re: [netmod] IPR poll on draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 12:58:33 -0000 --_000_VI1PR07MB404725309C259F90845899C2F03F0VI1PR07MB4047eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "No, I'm not aware of any IPR that applies to this draft" Regards Balazs From: Kent Watsen Sent: Tuesday, January 7, 2020 1:46 PM To: Bal=E1zs Lengyel ; Benoit Claise Cc: NETMOD Working Group Subject: IPR poll on draft-ietf-netmod-yang-instance-file-format To each author and contributor listed on the "To" line. In order to complete the WGLC poll, are you aware of any IPR that applies t= o draft-ietf-netmod-yang-instance-file-format? Please Reply-All to *this* em= ail and state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware of any = relevant IPR. This document will not advance to the next stage until a response has= been received from each author and listed contributor. NOTE: THIS APPLIES TO AL= L OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF IPR rules = which encourages you to notify the IETF if you are aware of IPR of others on an I= ETF contribution, or to refrain from participating in any contribution or discu= ssion related to your undisclosed IPR. For more information, please see the RFCs listed a= bove and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. NETMOD Chairs --_000_VI1PR07MB404725309C259F90845899C2F03F0VI1PR07MB4047eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    "No, I'm not aware of any IPR that applies to th= is draft"

    Regards Balazs

     

    From: Kent Watsen <kent+ietf@watsen.ne= t>
    Sent: Tuesday, January 7, 2020 1:46 PM
    To: Bal=E1zs Lengyel <balazs.lengyel@ericsson.com>; Benoit Cla= ise <bclaise@cisco.com>
    Cc: NETMOD Working Group <netmod@ietf.org>
    Subject: IPR poll on draft-ietf-netmod-yang-instance-file-format

     

    To each author and contributor listed on the "To= " line.


    In order to complete the WGLC poll, are you aware of any IPR that applies&n= bsp;to

    draft-ietf-netmod-yang-instance-file-format?  Pl= ease Reply-All to *this* email

    and state either:

    "No, I'm not aware of any IPR that applies to this draft"
    or
    "Yes, I'm aware of IPR that applies to this draft"

    If "yes", has this IPR been disclosed in compliance with IETF IPR= rules
    (see RFCs 3669, 5378 and 8179 for more details)?

    If "yes" again, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
    or
    "No, the IPR has not been disclosed"

    If you answer no, please provide any additional details you think appropria= te.

    If you are listed as a document author or contributor please answer the abo= ve by
    responding to this email regardless of whether or not you are aware of any = relevant
    IPR.  This document will not advance to the next stage until a respons= e has been
    received from each author and listed contributor.  NOTE: THIS APPLIES = TO ALL
    OF YOU LISTED IN THIS MESSAGE'S TO LINES.

    If you are on the WG email list or attend WG meetings but are not listed as= an author
    or contributor, we remind you of your obligations under the IETF IPR rules = which
    encourages you to notify the IETF if you are aware of IPR of others on an I= ETF
    contribution, or to refrain from participating in any contribution or discu= ssion related
    to your undisclosed IPR. For more information, please see the RFCs listed a= bove
    and 
    http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProper= ty.



    NETMOD Chairs



    --_000_VI1PR07MB404725309C259F90845899C2F03F0VI1PR07MB4047eurp_-- From nobody Tue Jan 7 05:06:23 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876101200F1 for ; Tue, 7 Jan 2020 05:06:22 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 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 L0L2Bnxad0I0 for ; Tue, 7 Jan 2020 05:06:20 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB910120044 for ; Tue, 7 Jan 2020 05:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10107; q=dns/txt; s=iport; t=1578402379; x=1579611979; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ddO48bCZctz2yQ8JEw5KYwSASvb7JMcos7ch7MGC9uE=; b=SeeC7nTE4htbIhadBzdZhnZ0tKuNu8QBp4oXWXpWt8Tusijn7JkHVeb2 1G+BSr5g5bRa/trb535Kb26RM73y9wi1giM0JI9sSW1OQdp5ibSPJK5XL T+N1pB+0Zu9hqfIxo6AcILrDybHbGUk7bcUNOUfFiTSV8kKs+WYnMLuHp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAAAVgRRe/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFrAgEBAQELAYEkU4EdVSASKo0MiCiTK4YkgWc?= =?us-ascii?q?JAQEBDAEBIwwBAYRAAoINNwYOAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDLUc?= =?us-ascii?q?FEAsRBAEBL08IBgEMBgIBAYMeAYJ3D6sigicfhTCDLoE9gTYBjDKBQT+BESe?= =?us-ascii?q?CbD6CWQsCgTABEgGFayIEjTqhZYJAhzWFO4kmBhuCR3aHB4Qci3+OU4hUiEK?= =?us-ascii?q?JSwIRFYFoI2dxMxoIGxU7gmwJRxgNlhmFQEADMAGMOYIyAQE?= X-IronPort-AV: E=Sophos; i="5.69,406,1571702400"; d="scan'208,217"; a="21396807" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 13:06:17 +0000 Received: from [10.228.43.9] ([10.228.43.9]) (authenticated bits=0) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPSA id 007D6FTE007835 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2020 13:06:17 GMT To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Kent Watsen Cc: NETMOD Working Group References: <0100016f800a15f0-e2786e5f-c870-44bf-8f2b-fbc6c863daa4-000000@email.amazonses.com> From: Benoit Claise Message-ID: <9cee6acc-8d1d-568f-befa-7ef3402d4100@cisco.com> Date: Tue, 7 Jan 2020 14:06:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------29E216C1F7D93F6389C565AA" Content-Language: en-US X-Authenticated-User: bclaise X-Outbound-SMTP-Client: 10.228.43.9, [10.228.43.9] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] IPR poll on draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:06:22 -0000 This is a multi-part message in MIME format. --------------29E216C1F7D93F6389C565AA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit "No, I'm not aware of any IPR that applies to this draft" Regards, B. > > "No, I'm not aware of any IPR that applies to this draft" > > Regards Balazs > > *From:* Kent Watsen > *Sent:* Tuesday, January 7, 2020 1:46 PM > *To:* BalŠzs Lengyel ; Benoit Claise > > *Cc:* NETMOD Working Group > *Subject:* IPR poll on draft-ietf-netmod-yang-instance-file-format > > To each author and contributor listed on the "To" line. > > > In order to complete the WGLC poll, are you aware of any IPR that > applies†to > > draft-ietf-netmod-yang-instance-file-format? †Please Reply-All to > *this* email > > and state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If "yes", has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If "yes" again, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by > responding to this email regardless of whether or not you are aware of > any relevant > IPR. †This document will not advance to the next stage until a > response has been > received from each author and listed contributor. †NOTE: THIS APPLIES > TO ALL > OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which > encourages you to notify the IETF if you are aware of IPR of others on > an IETF > contribution, or to refrain from participating in any contribution or > discussion related > to your undisclosed IPR. For more information, please see the RFCs > listed above > and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > > > NETMOD Chairs > > > --------------29E216C1F7D93F6389C565AA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
    "No, I'm not aware of any IPR that applies to this draft"

    Regards, B.

    "No, I'm not aware of any IPR that applies to this draft"

    Regards Balazs

    From: Kent Watsen <kent+ietf@watsen.net>
    Sent: Tuesday, January 7, 2020 1:46 PM
    To: BalŠzs Lengyel <balazs.lengyel@ericsson.com>; Benoit Claise <bclaise@cisco.com>
    Cc: NETMOD Working Group <netmod@ietf.org>
    Subject: IPR poll on draft-ietf-netmod-yang-instance-file-format

    To each author and contributor listed on the "To" line.


    In order to complete the WGLC poll, are you aware of any IPR that applies†to

    draft-ietf-netmod-yang-instance-file-format? †Please Reply-All to *this* email

    and state either:

    "No, I'm not aware of any IPR that applies to this draft"
    or
    "Yes, I'm aware of IPR that applies to this draft"

    If "yes", has this IPR been disclosed in compliance with IETF IPR rules
    (see RFCs 3669, 5378 and 8179 for more details)?

    If "yes" again, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
    or
    "No, the IPR has not been disclosed"

    If you answer no, please provide any additional details you think appropriate.

    If you are listed as a document author or contributor please answer the above by
    responding to this email regardless of whether or not you are aware of any relevant
    IPR. †This document will not advance to the next stage until a response has been
    received from each author and listed contributor. †NOTE: THIS APPLIES TO ALL
    OF YOU LISTED IN THIS MESSAGE'S TO LINES.

    If you are on the WG email list or attend WG meetings but are not listed as an author
    or contributor, we remind you of your obligations under the IETF IPR rules which
    encourages you to notify the IETF if you are aware of IPR of others on an IETF
    contribution, or to refrain from participating in any contribution or discussion related
    to your undisclosed IPR. For more information, please see the RFCs listed above
    and†
    http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.



    NETMOD Chairs




    --------------29E216C1F7D93F6389C565AA-- From nobody Tue Jan 7 05:39:07 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5DA120100 for ; Tue, 7 Jan 2020 05:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 N1fwpdh6pFDr for ; Tue, 7 Jan 2020 05:38:57 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 38E06120116 for ; Tue, 7 Jan 2020 05:38:57 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id AF9C01AE018C; Tue, 7 Jan 2020 14:38:54 +0100 (CET) Date: Tue, 07 Jan 2020 14:38:18 +0100 (CET) Message-Id: <20200107.143818.1928135118621633911.mbj@tail-f.com> To: balazs.lengyel=40ericsson.com@dmarc.ietf.org Cc: andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:39:06 -0000 Hi I agree w/ Andy and others that we should not add this to the import's description. I don't think this kind of conformance text belongs to the import's description. If you think it is important to state this, the best place is probably as plain text in the document itself. /martin Bal=E1zs Lengyel wrote= : > As a draft author who was asked to add text about the imports IMHO > = > * it would be easy for me to remove the description from the import. = Actually I really just want to know what is acceptable to the group, so= I can proceed > * I also think that adding this text is in most cases easy and it doe= s not need updates later. > * The rules in some cases might not be trivial. > = > * Imported YAMs need to be implemented if > = > * Imported parts are included in Xpath (augment, when, must, require-= instance) > = > * Imported YAMs do not need to be implemented if only the following a= re used > = > * Types > * Features > * extensions > = > * Ambiguous if > = > * groupings are used > * if the dependency is not formally defined by YANG, but functionally= needed. (E.g. notification-capabilities does not formally need YANG-Pu= sh to be implemented, however there is no sense in defining capabilitie= s if YANG-Push is itself not implemented.) > * deviation ? > * other cases ? > = > Regards Balazs > = > = > = > From: netmod On Behalf Of Andy Bierman > Sent: 2019. december 19., cs=FCt=F6rt=F6k 17:23 > To: Ladislav Lhotka > Cc: NetMod WG > Subject: Re: [netmod] Text in import to indicate whether a module is = needed as import-only or as implemented > = > = > = > = > = > = > = > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > wrote: > = > On Thu, 2019-12-19 at 07:52 +0000, Sch=F6nw=E4lder, J=FCrgen wrote: > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote: > > > I don't see how YANG syntax defines this. If a module imports iet= f-netconf- > > > acm, it could be because > > > = > > > - it just uses a typedef, such as "node-instance-identifier", and= then > > > ietf-netconf-acm needn't be implemented (but can be), > > > = > > > or > > > = > > > - it augments ietf-netconf-acm, which makes sense only if the lat= ter > > > module is implemented. > > > = > > > It it the YANG library that specifies whether a module is impleme= nted or > > > not, but the "import" statement itself doesn't tell you anything.= > > > = > > = > > Can we not assume that an implementor will figure out the differenc= e? > = > An implementor should be able to figure it out, but other potential m= odule users > may not. For example, if somebody is evaluating whether to use a modu= le for > their device or not, it is important to know that NACM has to be impl= emented (or > not). > = > = > = > You seem to be talking about a new conformance documentation procedur= e > = > that attempts to solve the problem "to use modules A, B, and C togeth= er > = > to achieve some functionality X, all these conditions need to be met"= .= > = > (Sounds more like a problem for YANG Packages to solve) > = > = > = > IMO this is a much harder problem than something that can be solved > = > with extra description-stmt text. The writer is likely to get it wron= g or not > = > keep it up to date, so a tool to analyze the file seems like a better= solution. > = > = > = > Lada > = > = > = > = > = > Andy > = > = > = > = > > Or someone writes a pyang plugin to determine from the schema tree = the > > kind of imports there are (for a given set of features). > > = > > /js > > = > -- = > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > = > _______________________________________________ > netmod mailing list > netmod@ietf.org = > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Tue Jan 7 06:30:03 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EA01200E0 for ; Tue, 7 Jan 2020 06:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NOtK7X-inlgD for ; Tue, 7 Jan 2020 06:29:59 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2066.outbound.protection.outlook.com [40.107.22.66]) (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 BC27B120059 for ; Tue, 7 Jan 2020 06:29:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lbnxn6CC9a68djTU+KAzc2nmnb7BMqc2uZEknhDSUQ+dDpVy60lEd8VYw/C76cE7Lvwu4I94Rud40BOu3LICootU9ahakno5tMXC+29I2YaIsItcVel/sBPIFF8ocvC0sh3VTIpn8Hi1LtK0seXdAXzbliBu63YTSEVKjWflOLAL2rwHnKF2yDxP1z24XIJfXUYrtv/uCAK+Oc7qpYz5fZQ4zpczV95/8lnmJdA29iUuRc13Djux0zl8NdMho5Z/xyG/41iLyqF34Wd24i59HBqc7xRIRjl3AQtr03fPHsteCiRzf3F40n5Srxcq3h7YXmQ9sqmDXlNY8aJ2X/7+9g== 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=PQCjUAGR8480B3E7ympY8QjtJzLtPno8TH2kw2fq5nE=; b=GNdhgbIWJNuU9fh9jNC4IzWK/SYEEF4dU+ZwjrA6lXocD2n78x3MSFzIN+7LoqaF7jv3XJK3MY5NSvQp99oX3iFpxKo0q2qH0g/h81MMlW91k4UY7EjcDx1vHOpQoCp7dMeqMScgG3EM1X3Kv3BaiRONzJq288W0rssaP/CDvbamxxlfLxn+WccQU5DZdSCZDZXubC9qBeKiLQhg3nvXo730oL+tKP6p5HCP+S/WNdkGHWK80I4j2uMES+qVfTZvBMwIH55ZeMJjJszmbiLJ72SmxInPivBYJHKlYWU/4vJKZ57AytWx1T0j5xqoZeApxSmt5fbpjMfSx8rADik7Jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PQCjUAGR8480B3E7ympY8QjtJzLtPno8TH2kw2fq5nE=; b=NfRZodD2neprKhEDgvNtd7MUTShSGb9QTsoc8VUP4UQWiHxUgn61ivVV9i7qEZ8s8vQqvIVpy6Rc3bab5PvYJ3EcSIYn2U+oyfyeaZbQEkAfuzQgfNlE7xtOnA/weBrqErC9tEkrB1PCRzJLVLsmX4ko6Pvhe/nHTkUAeu795yM= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB3181.eurprd07.prod.outlook.com (10.170.238.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.6; Tue, 7 Jan 2020 14:29:56 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2623.008; Tue, 7 Jan 2020 14:29:56 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Martin Bjorklund CC: "andy@yumaworks.com" , "lhotka@nic.cz" , "netmod@ietf.org" Thread-Topic: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented Thread-Index: AdW1rIivNNF/ygLlRsqN7vYQ6ujj8wAHQSMAABzp24AAAQTrAAARCBUAAADIkQAC4vIRcADS2UAAAAG/CEA= Date: Tue, 7 Jan 2020 14:29:56 +0000 Message-ID: References: <20200107.143818.1928135118621633911.mbj@tail-f.com> In-Reply-To: <20200107.143818.1928135118621633911.mbj@tail-f.com> 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=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58ac58f7-0384-4315-83c1-08d7937e1196 x-ms-traffictypediagnostic: VI1PR07MB3181: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(366004)(376002)(39860400002)(189003)(199004)(13464003)(6506007)(53546011)(81156014)(2906002)(66946007)(7696005)(186003)(478600001)(66476007)(71200400001)(66446008)(64756008)(26005)(76116006)(66556008)(81166006)(8676002)(8936002)(316002)(966005)(4326008)(4001150100001)(33656002)(86362001)(55016002)(5660300002)(66574012)(52536014)(54906003)(6916009)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3181; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IUzqW/Exmlp5xZEOEhBgrm2hnYQA9/agBsV6Nqmx777Gxxws1TJ4O4J5Way+E969FFzMoUGtcZRTI+/1k/T+ZUFCDitUkQ2vd3W7Vr29pD9ZBN6azyXvPxUH3nGTiZF97MV9Ukh7KBxvoNlczPICT66rP8GuwT+UjuYQ+lng+T1Lv+6CNX82utNkCcyRu59WjRWzbAv7ffscZ75OAS1IkCQsFiEVV/NVS7PN2Pdw8H2U94uh9Pi3xE/pkbN6MB4pIrBQZTgRxIZj26xChliMckrvdw54HwHa3m2ClnoWmlUt0xlIndPo+5RVZrr4RYvsvlC9AkG66LduBo+UfHVVwWKuGMkVRQ9C5f1rXhU/DdTA494UkKSki7Y/zTYHMkVorGEkKv+kKJ/oUXwSC1J4jbiMMa3JQxoYjj6bmlupGjoUZn+xwftkIBtZgGEY+fosT2RJ6Q7Gm5wjj5MuhQ8CHKEfDpsQpcuhYbigKckaSxILJpvyqH74aA4BLrMVXWJL2RpWhBzfzpOcWJMr9osDhNjWBYnYy2SUIPG099r0wC8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58ac58f7-0384-4315-83c1-08d7937e1196 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 14:29:56.5194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: g5KIZG6/WasOAHEKAEzcIZCQxeIEhAzAJ/xTNN54MHYPmcwjL3inyw3otxqNHPZBSb5bHyctpOSuPbqr45z5JvOfprEIuMal9FpyN/bHuWI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3181 Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 14:30:02 -0000 If that is the consensus, I can remove the description statements, no big d= eal. (I actually like the statements, but they are not important for this d= raft) Balazs -----Original Message----- From: Martin Bjorklund =20 Sent: Tuesday, January 7, 2020 2:38 PM To: Bal=E1zs Lengyel Cc: andy@yumaworks.com; lhotka@nic.cz; netmod@ietf.org Subject: Re: [netmod] Text in import to indicate whether a module is needed= as import-only or as implemented Hi I agree w/ Andy and others that we should not add this to the import's desc= ription. I don't think this kind of conformance text belongs to the import= 's description. If you think it is important to state this, the best place= is probably as plain text in the document itself. /martin Bal=E1zs Lengyel wrote: > As a draft author who was asked to add text about the imports IMHO >=20 > * it would be easy for me to remove the description from the import. Actu= ally I really just want to know what is acceptable to the group, so I can p= roceed > * I also think that adding this text is in most cases easy and it does no= t need updates later. > * The rules in some cases might not be trivial. >=20 > * Imported YAMs need to be implemented if >=20 > * Imported parts are included in Xpath (augment, when, must, require-inst= ance) >=20 > * Imported YAMs do not need to be implemented if only the following are u= sed >=20 > * Types > * Features > * extensions >=20 > * Ambiguous if >=20 > * groupings are used > * if the dependency is not formally defined by YANG, but functionally nee= ded. (E.g. notification-capabilities does not formally need YANG-Push to be= implemented, however there is no sense in defining capabilities if YANG-Pu= sh is itself not implemented.) > * deviation ? > * other cases ? >=20 > Regards Balazs >=20 > =20 >=20 > From: netmod On Behalf Of Andy Bierman > Sent: 2019. december 19., cs=FCt=F6rt=F6k 17:23 > To: Ladislav Lhotka > Cc: NetMod WG > Subject: Re: [netmod] Text in import to indicate whether a module is=20 > needed as import-only or as implemented >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > wrote: >=20 > On Thu, 2019-12-19 at 07:52 +0000, Sch=F6nw=E4lder, J=FCrgen wrote: > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote: > > > I don't see how YANG syntax defines this. If a module imports=20 > > > ietf-netconf- acm, it could be because > > >=20 > > > - it just uses a typedef, such as "node-instance-identifier", and the= n > > > ietf-netconf-acm needn't be implemented (but can be), > > >=20 > > > or > > >=20 > > > - it augments ietf-netconf-acm, which makes sense only if the latter > > > module is implemented. > > >=20 > > > It it the YANG library that specifies whether a module is=20 > > > implemented or not, but the "import" statement itself doesn't tell yo= u anything. > > >=20 > >=20 > > Can we not assume that an implementor will figure out the difference? >=20 > An implementor should be able to figure it out, but other potential=20 > module users may not. For example, if somebody is evaluating whether=20 > to use a module for their device or not, it is important to know that=20 > NACM has to be implemented (or not). >=20 > =20 >=20 > You seem to be talking about a new conformance documentation procedure >=20 > that attempts to solve the problem "to use modules A, B, and C=20 > together >=20 > to achieve some functionality X, all these conditions need to be met".. >=20 > (Sounds more like a problem for YANG Packages to solve) >=20 > =20 >=20 > IMO this is a much harder problem than something that can be solved >=20 > with extra description-stmt text. The writer is likely to get it wrong=20 > or not >=20 > keep it up to date, so a tool to analyze the file seems like a better sol= ution. >=20 > =20 >=20 > Lada >=20 > =20 >=20 > =20 >=20 > Andy >=20 > =20 >=20 >=20 > > Or someone writes a pyang plugin to determine from the schema tree=20 > > the kind of imports there are (for a given set of features). > >=20 > > /js > >=20 > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Wed Jan 8 01:11:55 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B046612002F for ; Wed, 8 Jan 2020 01:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=nic.cz 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 SunCr-UAXKh1 for ; Wed, 8 Jan 2020 01:11:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 C59D21200E3 for ; Wed, 8 Jan 2020 01:11:51 -0800 (PST) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id DB601140B85; Wed, 8 Jan 2020 10:11:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1578474710; bh=2UZjjlMwntDQ0oHiuAa3AT9jl1In6dKUucP7P5YEfbU=; h=From:To:Date; b=wmX9AS/ak4+WBymxutw3O5x/PEuicvqHi1xXUUEDWSx8l8MNEPMmJuH1tQlLDH60I 3VXGn9OaJuBo3pKsbbvx9sGXj0/uG0j32cMuvXlL6HRa47gjTf5V+FH3ETpfTonL4W X8IAZh/LBvedDKCPyTYBSasPoK0rJxNF01nT9LGM= Message-ID: From: Ladislav Lhotka To: =?ISO-8859-1?Q?Bal=E1zs?= Lengyel , Martin Bjorklund Cc: "andy@yumaworks.com" , "netmod@ietf.org" Date: Wed, 08 Jan 2020 10:11:49 +0100 In-Reply-To: References: <20200107.143818.1928135118621633911.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:11:55 -0000 On Tue, 2020-01-07 at 14:29 +0000, Bal√°zs Lengyel wrote: > If that is the consensus, I can remove the description statements, no big > deal. (I actually like the statements, but they are not important for this > draft) Of course, it is not that important, but I don't see how this information could be harmful, if it is included with the import. In my view, it is not meant as a conformance requirement but just an info from the module author about the meaning of the import statement. The root of this problem (and design flaw of YANG, IMO) is that import is "overloaded" with two different purposes, one of which effectively requires that the imported module be also implemented, while the other doesn't. Lada > Balazs > > -----Original Message----- > From: Martin Bjorklund > Sent: Tuesday, January 7, 2020 2:38 PM > To: Bal√°zs Lengyel > Cc: andy@yumaworks.com; lhotka@nic.cz; netmod@ietf.org > Subject: Re: [netmod] Text in import to indicate whether a module is needed as > import-only or as implemented > > Hi > > I agree w/ Andy and others that we should not add this to the import's > description. I don't think this kind of conformance text belongs to the > import's description. If you think it is important to state this, the best > place is probably as plain text in the document itself. > > > > /martin > > > Bal√°zs Lengyel wrote: > > As a draft author who was asked to add text about the imports IMHO > > > > * it would be easy for me to remove the description from the import. > > Actually I really just want to know what is acceptable to the group, so I > > can proceed > > * I also think that adding this text is in most cases easy and it does not > > need updates later. > > * The rules in some cases might not be trivial. > > > > * Imported YAMs need to be implemented if > > > > * Imported parts are included in Xpath (augment, when, must, require- > > instance) > > > > * Imported YAMs do not need to be implemented if only the following are > > used > > > > * Types > > * Features > > * extensions > > > > * Ambiguous if > > > > * groupings are used > > * if the dependency is not formally defined by YANG, but functionally > > needed. (E.g. notification-capabilities does not formally need YANG-Push to > > be implemented, however there is no sense in defining capabilities if YANG- > > Push is itself not implemented.) > > * deviation ? > > * other cases ? > > > > Regards Balazs > > > > > > > > From: netmod On Behalf Of Andy Bierman > > Sent: 2019. december 19., cs√ľt√∂rt√∂k 17:23 > > To: Ladislav Lhotka > > Cc: NetMod WG > > Subject: Re: [netmod] Text in import to indicate whether a module is > > needed as import-only or as implemented > > > > > > > > > > > > > > > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > lhotka@nic.cz> > wrote: > > > > On Thu, 2019-12-19 at 07:52 +0000, Sch√∂nw√§lder, J√ľrgen wrote: > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote: > > > > I don't see how YANG syntax defines this. If a module imports > > > > ietf-netconf- acm, it could be because > > > > > > > > - it just uses a typedef, such as "node-instance-identifier", and then > > > > ietf-netconf-acm needn't be implemented (but can be), > > > > > > > > or > > > > > > > > - it augments ietf-netconf-acm, which makes sense only if the latter > > > > module is implemented. > > > > > > > > It it the YANG library that specifies whether a module is > > > > implemented or not, but the "import" statement itself doesn't tell you > > > > anything. > > > > > > > > > > Can we not assume that an implementor will figure out the difference? > > > > An implementor should be able to figure it out, but other potential > > module users may not. For example, if somebody is evaluating whether > > to use a module for their device or not, it is important to know that > > NACM has to be implemented (or not). > > > > > > > > You seem to be talking about a new conformance documentation procedure > > > > that attempts to solve the problem "to use modules A, B, and C > > together > > > > to achieve some functionality X, all these conditions need to be met".. > > > > (Sounds more like a problem for YANG Packages to solve) > > > > > > > > IMO this is a much harder problem than something that can be solved > > > > with extra description-stmt text. The writer is likely to get it wrong > > or not > > > > keep it up to date, so a tool to analyze the file seems like a better > > solution. > > > > > > > > Lada > > > > > > > > > > > > Andy > > > > > > > > > > > Or someone writes a pyang plugin to determine from the schema tree > > > the kind of imports there are (for a given set of features). > > > > > > /js > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 8 04:50:09 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27145120111 for ; Wed, 8 Jan 2020 04:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 E99RFzRuZv1B for ; Wed, 8 Jan 2020 04:50:05 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D79120026 for ; Wed, 8 Jan 2020 04:50:05 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id i23so2353142lfo.7 for ; Wed, 08 Jan 2020 04:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=flBiyT0yQ4wKuhLX/jZceGE5QeKxDH8Zp1awF53RQ70=; b=rV1rjMpx0Vud1Dl079ZdWNigcGNSIcDX4LZP6koDTtQr58n+D+R11dUevHkl1EpwJy LVdrMZDABHMSFLdJq8Am28aBUshcXlbfXwkRu5zqpBqKP1tASkU46Rv+Bq+zJViwdWH0 wpGJP85tAaFrXO9Idh/V5GF/LwIz/BRRSAiSHLASZna5cXrgqhei8RL/4Z8mzRHARR++ 4Mqam7YYAu7PuySYfw9IzbCc78QOqZXnnEPqsd//5tUpnLycbK73ST0At1B415uVEIdU gWD8Q9QL9+xBpq7fSLssZbDOYA3/CL1EM3rbNHOJvVMlCSHtuH317bvvYwZt8+TREktP DqRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=flBiyT0yQ4wKuhLX/jZceGE5QeKxDH8Zp1awF53RQ70=; b=bfpVKAecXVb5O7lRncMEHG+WapqVEqxnVd84beOTkEWpEjDIIhaEQtuBcU/7ddq5Qy PNlB+sBTF/cD1A6gHQ7aXZHw02E7kx2nS9WKZvzMWIZ9+KMPocSf9P4EYVcmIpTvHB21 q2ZUGVIScNW8tTYvpOnkuaBPCiywc29oNPMUGeXp9rxEYBFAMf4rZczmr2QY7ma6t6FJ 7kUQs6Cw7ks3D6S86L9lS5RJGgI8PqzSO7JtdQ1zZwgxs40dl1Fza11uwvVxupo9GO9v snKW3MTbwU/uS9Mq4rGvHQTq+PC6b+QyRFJTBGwqRUjlSaCQXyezzFa0NMmCZNz4MmLE ICqA== X-Gm-Message-State: APjAAAVyinmgNgrQTJnKnhmjiKgpD/C/oJsHPCpnLI/OhgiQzTBbsoqB d6hBs77FrIlTfEt/H/WNHfFhaNF8ofCoIGZMfqKpAg== X-Google-Smtp-Source: APXvYqyM0lM5ur8k7l8tJImnV6jwauOUGDsV+WZFdJgZqgRWTaGD5bCtAF5RbYUA7C7J3dtNynSYRkpuRQmCpb8LM28= X-Received: by 2002:a19:4b87:: with SMTP id y129mr3007922lfa.32.1578487803440; Wed, 08 Jan 2020 04:50:03 -0800 (PST) MIME-Version: 1.0 References: <20200107.143818.1928135118621633911.mbj@tail-f.com> In-Reply-To: From: Andy Bierman Date: Wed, 8 Jan 2020 04:49:52 -0800 Message-ID: To: Ladislav Lhotka Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ce88d9059ba05415" Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:50:08 -0000 --000000000000ce88d9059ba05415 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka wrote: > On Tue, 2020-01-07 at 14:29 +0000, Bal=C3=A1zs Lengyel wrote: > > If that is the consensus, I can remove the description statements, no b= ig > > deal. (I actually like the statements, but they are not important for > this > > draft) > > Of course, it is not that important, but I don't see how this information > could > be harmful, if it is included with the import. In my view, it is not mean= t > as a > conformance requirement but just an info from the module author about the > meaning of the import statement. > > It adds a lot of extra work but more importantly the import-stmt is the wrong place to document such a complex and unrelated issue as server conformance requirements. The root of this problem (and design flaw of YANG, IMO) is that import is > "overloaded" with two different purposes, one of which effectively > requires that > the imported module be also implemented, while the other doesn't. > > The import-stmt is only used to map a local prefix to an external module. This proposal to add conformance info the the import-stmt would overload it with another purpose. Not even a typedef is easy to classify (e.g., leafref requires implementation of a data node). I certainly agree that YANG conformance is poorly specified, poorly understood, and in real need of improvement. Likewise, the import-stmt is also in need of some improvement since import-by-exact-revision is (and has always been) poorly designed. Lada > > > Balazs > Andy > > > > -----Original Message----- > > From: Martin Bjorklund > > Sent: Tuesday, January 7, 2020 2:38 PM > > To: Bal=C3=A1zs Lengyel > > Cc: andy@yumaworks.com; lhotka@nic.cz; netmod@ietf.org > > Subject: Re: [netmod] Text in import to indicate whether a module is > needed as > > import-only or as implemented > > > > Hi > > > > I agree w/ Andy and others that we should not add this to the import's > > description. I don't think this kind of conformance text belongs to th= e > > import's description. If you think it is important to state this, the > best > > place is probably as plain text in the document itself. > > > > > > > > /martin > > > > > > Bal=C3=A1zs Lengyel wr= ote: > > > As a draft author who was asked to add text about the imports IMHO > > > > > > * it would be easy for me to remove the description from the import= . > > > Actually I really just want to know what is acceptable to the group, > so I > > > can proceed > > > * I also think that adding this text is in most cases easy and it > does not > > > need updates later. > > > * The rules in some cases might not be trivial. > > > > > > * Imported YAMs need to be implemented if > > > > > > * Imported parts are included in Xpath (augment, when, must, requir= e- > > > instance) > > > > > > * Imported YAMs do not need to be implemented if only the following > are > > > used > > > > > > * Types > > > * Features > > > * extensions > > > > > > * Ambiguous if > > > > > > * groupings are used > > > * if the dependency is not formally defined by YANG, but functional= ly > > > needed. (E.g. notification-capabilities does not formally need > YANG-Push to > > > be implemented, however there is no sense in defining capabilities if > YANG- > > > Push is itself not implemented.) > > > * deviation ? > > > * other cases ? > > > > > > Regards Balazs > > > > > > > > > > > > From: netmod On Behalf Of Andy Bierman > > > Sent: 2019. december 19., cs=C3=BCt=C3=B6rt=C3=B6k 17:23 > > > To: Ladislav Lhotka > > > Cc: NetMod WG > > > Subject: Re: [netmod] Text in import to indicate whether a module is > > > needed as import-only or as implemented > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > > lhotka@nic.cz> > wrote: > > > > > > On Thu, 2019-12-19 at 07:52 +0000, Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen= wrote: > > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote: > > > > > I don't see how YANG syntax defines this. If a module imports > > > > > ietf-netconf- acm, it could be because > > > > > > > > > > - it just uses a typedef, such as "node-instance-identifier", and > then > > > > > ietf-netconf-acm needn't be implemented (but can be), > > > > > > > > > > or > > > > > > > > > > - it augments ietf-netconf-acm, which makes sense only if the > latter > > > > > module is implemented. > > > > > > > > > > It it the YANG library that specifies whether a module is > > > > > implemented or not, but the "import" statement itself doesn't tel= l > you > > > > > anything. > > > > > > > > > > > > > Can we not assume that an implementor will figure out the differenc= e? > > > > > > An implementor should be able to figure it out, but other potential > > > module users may not. For example, if somebody is evaluating whether > > > to use a module for their device or not, it is important to know that > > > NACM has to be implemented (or not). > > > > > > > > > > > > You seem to be talking about a new conformance documentation procedur= e > > > > > > that attempts to solve the problem "to use modules A, B, and C > > > together > > > > > > to achieve some functionality X, all these conditions need to be met"= .. > > > > > > (Sounds more like a problem for YANG Packages to solve) > > > > > > > > > > > > IMO this is a much harder problem than something that can be solved > > > > > > with extra description-stmt text. The writer is likely to get it wron= g > > > or not > > > > > > keep it up to date, so a tool to analyze the file seems like a better > > > solution. > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > Or someone writes a pyang plugin to determine from the schema tree > > > > the kind of imports there are (for a given set of features). > > > > > > > > /js > > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > --000000000000ce88d9059ba05415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Wed, Jan 8, 2020 at 1:11 AM Ladisl= av Lhotka <lhotka@nic.cz> wrote:=
    On Tue, 2020-01= -07 at 14:29 +0000, Bal=C3=A1zs Lengyel wrote:
    > If that is the consensus, I can remove the description statements, no = big
    > deal. (I actually like the statements, but they are not important for = this
    > draft)

    Of course, it is not that important, but I don't see how this informati= on could
    be harmful, if it is included with the import. In my view, it is not meant = as a
    conformance requirement but just an info from the module author about the meaning of the import statement.


    It adds a lot of extra work but more i= mportantly the import-stmt is the wrong place
    to document such a = complex and unrelated=C2=A0issue as server conformance requirements.
    <= div>

    The root of this problem (and design flaw of YANG, IMO) is that import is "overloaded" with two different purposes, one of which effectivel= y requires that
    the imported module be also implemented, while the other doesn't.


    The import-stmt is only used to map a = local prefix to an external module.
    This proposal to add conforma= nce=C2=A0info the the import-stmt would overload it with
    another = purpose.

    Not even a typedef is easy to classify=C2= =A0 (e.g., leafref requires implementation of a data node).
    I cer= tainly agree that YANG conformance is poorly specified, poorly understood, = and
    in real need of improvement. Likewise, the import-stmt is als= o in need of some improvement
    since import-by-exact-revision is (= and has always been) poorly designed.


    Lada

    > Balazs

    Andy

    =C2=A0
    >
    > -----Original Message-----
    > From: Martin Bjorklund <mbj@tail-f.com>
    > Sent: Tuesday, January 7, 2020 2:38 PM
    > To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
    > Cc: andy@yumaw= orks.com; lhotka@nic= .cz; netmod@ietf.o= rg
    > Subject: Re: [netmod] Text in import to indicate whether a module is n= eeded as
    > import-only or as implemented
    >
    > Hi
    >
    > I agree w/ Andy and others that we should not add this to the import&#= 39;s
    > description.=C2=A0 I don't think this kind of conformance text bel= ongs to the
    > import's description.=C2=A0 If you think it is important to state = this, the best
    > place is probably as plain text in the document itself.
    >
    >
    >
    > /martin
    >
    >
    > Bal=C3=A1zs Lengyel <balazs.lengyel=3D40ericsson.com@dmarc.ietf.org>= wrote:
    > > As a draft author who was asked to add text about the imports IMH= O
    > >
    > > *=C2=A0 =C2=A0it would be easy for me to remove the description f= rom the import.
    > > Actually I really just want to know what is acceptable to the gro= up, so I
    > > can proceed
    > > *=C2=A0 =C2=A0I also think that adding this text is in most cases= easy and it does not
    > > need updates later.
    > > *=C2=A0 =C2=A0The rules in some cases might not be trivial.
    > >
    > > *=C2=A0 =C2=A0Imported YAMs need to be implemented if
    > >
    > > *=C2=A0 =C2=A0Imported parts are included in Xpath (augment, when= , must, require-
    > > instance)
    > >
    > > *=C2=A0 =C2=A0Imported YAMs do not need to be implemented if only= the following are
    > > used
    > >
    > > *=C2=A0 =C2=A0Types
    > > *=C2=A0 =C2=A0Features
    > > *=C2=A0 =C2=A0extensions
    > >
    > > *=C2=A0 =C2=A0Ambiguous if
    > >
    > > *=C2=A0 =C2=A0groupings are used
    > > *=C2=A0 =C2=A0if the dependency is not formally defined by YANG, = but functionally
    > > needed. (E.g. notification-capabilities does not formally need YA= NG-Push to
    > > be implemented, however there is no sense in defining capabilitie= s if YANG-
    > > Push is itself not implemented.)
    > > *=C2=A0 =C2=A0deviation ?
    > > *=C2=A0 =C2=A0other cases ?
    > >
    > > Regards Balazs
    > >
    > >=C2=A0
    > >
    > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
    > > Sent: 2019. december 19., cs=C3=BCt=C3=B6rt=C3=B6k 17:23
    > > To: Ladislav Lhotka <lhotka@nic.cz>
    > > Cc: NetMod WG <netmod@ietf.org>
    > > Subject: Re: [netmod] Text in import to indicate whether a module= is
    > > needed as import-only or as implemented
    > >
    > >=C2=A0
    > >
    > >=C2=A0
    > >
    > >=C2=A0
    > >
    > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka <lhotka@nic.cz <mailto:
    > > lhotka@nic.cz<= /a>> > wrote:
    > >
    > > On Thu, 2019-12-19 at 07:52 +0000, Sch=C3=B6nw=C3=A4lder, J=C3=BC= rgen wrote:
    > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wr= ote:
    > > > > I don't see how YANG syntax defines this. If a modu= le imports
    > > > > ietf-netconf- acm, it could be because
    > > > >
    > > > > - it just uses a typedef, such as "node-instance-i= dentifier", and then
    > > > >=C2=A0 =C2=A0ietf-netconf-acm needn't be implemented= (but can be),
    > > > >
    > > > > or
    > > > >
    > > > > - it augments ietf-netconf-acm, which makes sense only = if the latter
    > > > >=C2=A0 =C2=A0module is implemented.
    > > > >
    > > > > It it the YANG library that specifies whether a module = is
    > > > > implemented or not, but the "import" statemen= t itself doesn't tell you
    > > > > anything.
    > > > >
    > > >
    > > > Can we not assume that an implementor will figure out the di= fference?
    > >
    > > An implementor should be able to figure it out, but other potenti= al
    > > module users may not. For example, if somebody is evaluating whet= her
    > > to use a module for their device or not, it is important to know = that
    > > NACM has to be implemented (or not).
    > >
    > >=C2=A0
    > >
    > > You seem to be talking about a new conformance documentation proc= edure
    > >
    > > that attempts to solve the problem "to use modules A, B, and= C
    > > together
    > >
    > > to achieve some functionality X, all these conditions need to be = met"..
    > >
    > > (Sounds more like a problem for YANG Packages to solve)
    > >
    > >=C2=A0
    > >
    > > IMO this is a much harder problem than something that can be solv= ed
    > >
    > > with extra description-stmt text. The writer is likely to get it = wrong
    > > or not
    > >
    > > keep it up to date, so a tool to analyze the file seems like a be= tter
    > > solution.
    > >
    > >=C2=A0
    > >
    > > Lada
    > >
    > >=C2=A0
    > >
    > >=C2=A0
    > >
    > > Andy
    > >
    > >=C2=A0
    > >
    > >
    > > > Or someone writes a pyang plugin to determine from the schem= a tree
    > > > the kind of imports there are (for a given set of features).=
    > > >
    > > > /js
    > > >
    > > --
    > > Ladislav Lhotka
    > > Head, CZ.NIC Labs
    > > PGP Key ID: 0xB8F92B08A9F76C67
    > >
    > > _______________________________________________
    > > netmod mailing list
    > >
    netmod@ietf.= org <mailto:net= mod@ietf.org>
    > > https://www.ietf.org/mailman/listinfo/netmod
    > >
    --
    Ladislav Lhotka
    Head, CZ.NIC Labs
    PGP Key ID: 0xB8F92B08A9F76C67

    --000000000000ce88d9059ba05415-- From nobody Wed Jan 8 05:44:05 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9A41200FE for ; Wed, 8 Jan 2020 05:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=nic.cz 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 0S_mlavnte3w for ; Wed, 8 Jan 2020 05:43:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 5B718120892 for ; Wed, 8 Jan 2020 05:43:54 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 4922013F96F for ; Wed, 8 Jan 2020 14:43:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1578491032; bh=ORrLQkPKCb+62lzoWkmZgNmbHybQ9Av5aNJdrNQGZYw=; h=From:To:Date; b=dl2VEzyenRD5/lwt8Uwp/HQuvyQJEvj5WgFzptrAXOIWjEnDAzd9/7UBjo+K2TTBN zBxcR5PdJcbXWu3lMwyHiN4BRNtMAzV5UA5lj+SsObaCuQNB+97EFClup5OTfpJqNb 5k4vgu7cqJQdSFAO4dSOFdGl6l/CWfyzWOAwm8hQ= Message-ID: From: Ladislav Lhotka To: NETMOD WG Date: Wed, 08 Jan 2020 14:43:52 +0100 In-Reply-To: References: <20200107.143818.1928135118621633911.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:44:03 -0000 On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote: > > On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka wrote: > > On Tue, 2020-01-07 at 14:29 +0000, Bal√°zs Lengyel wrote: > > > If that is the consensus, I can remove the description statements, no big > > > deal. (I actually like the statements, but they are not important for this > > > draft) > > > > Of course, it is not that important, but I don't see how this information > > could > > be harmful, if it is included with the import. In my view, it is not meant > > as a > > conformance requirement but just an info from the module author about the > > meaning of the import statement. > > > > It adds a lot of extra work but more importantly the import-stmt is the wrong > place What work do you mean? I thought that it would be just info for potential developers (or their managers) that implementing the module requires implementing other modules and functionality - or not. For example, if a module imports ietf-netconf-nacm only for using "node- instance-identifier" type, it is relatively uninteresting. Otherwise, implementation of the module may just be out of question. > to document such a complex and unrelated issue as server conformance > requirements. > > > > The root of this problem (and design flaw of YANG, IMO) is that import is > > "overloaded" with two different purposes, one of which effectively requires > > that > > the imported module be also implemented, while the other doesn't. > > > > The import-stmt is only used to map a local prefix to an external module. But one thing is using a prefix for accessing top-level types and groupings (i.e. stuff in YANG modules), and another thing is accessing schema nodes, which have to be present in the schema tree. In complicated data models, it is not exactly easy to figure out all these dependencies. So maybe what is really overloaded are the namespace prefixes: they are used for addressing YANG modules, schema nodes and instances (in XPath). Lada > This proposal to add conformance info the the import-stmt would overload it > with > another purpose. > > Not even a typedef is easy to classify (e.g., leafref requires implementation > of a data node). > I certainly agree that YANG conformance is poorly specified, poorly > understood, and > in real need of improvement. Likewise, the import-stmt is also in need of some > improvement > since import-by-exact-revision is (and has always been) poorly designed. > > > > Lada > > > > > Balazs > > Andy > > > > > -----Original Message----- > > > From: Martin Bjorklund > > > Sent: Tuesday, January 7, 2020 2:38 PM > > > To: Bal√°zs Lengyel > > > Cc: andy@yumaworks.com; lhotka@nic.cz; netmod@ietf.org > > > Subject: Re: [netmod] Text in import to indicate whether a module is > > needed as > > > import-only or as implemented > > > > > > Hi > > > > > > I agree w/ Andy and others that we should not add this to the import's > > > description. I don't think this kind of conformance text belongs to the > > > import's description. If you think it is important to state this, the > > best > > > place is probably as plain text in the document itself. > > > > > > > > > > > > /martin > > > > > > > > > Bal√°zs Lengyel wrote: > > > > As a draft author who was asked to add text about the imports IMHO > > > > > > > > * it would be easy for me to remove the description from the import. > > > > Actually I really just want to know what is acceptable to the group, so > > I > > > > can proceed > > > > * I also think that adding this text is in most cases easy and it does > > not > > > > need updates later. > > > > * The rules in some cases might not be trivial. > > > > > > > > * Imported YAMs need to be implemented if > > > > > > > > * Imported parts are included in Xpath (augment, when, must, require- > > > > instance) > > > > > > > > * Imported YAMs do not need to be implemented if only the following > > are > > > > used > > > > > > > > * Types > > > > * Features > > > > * extensions > > > > > > > > * Ambiguous if > > > > > > > > * groupings are used > > > > * if the dependency is not formally defined by YANG, but functionally > > > > needed. (E.g. notification-capabilities does not formally need YANG- > > > > Push > > to > > > > be implemented, however there is no sense in defining capabilities if > > YANG- > > > > Push is itself not implemented.) > > > > * deviation ? > > > > * other cases ? > > > > > > > > Regards Balazs > > > > > > > > > > > > > > > > From: netmod On Behalf Of Andy Bierman > > > > Sent: 2019. december 19., cs√ľt√∂rt√∂k 17:23 > > > > To: Ladislav Lhotka > > > > Cc: NetMod WG > > > > Subject: Re: [netmod] Text in import to indicate whether a module is > > > > needed as import-only or as implemented > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > > > lhotka@nic.cz> > wrote: > > > > > > > > On Thu, 2019-12-19 at 07:52 +0000, Sch√∂nw√§lder, J√ľrgen wrote: > > > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote: > > > > > > I don't see how YANG syntax defines this. If a module imports > > > > > > ietf-netconf- acm, it could be because > > > > > > > > > > > > - it just uses a typedef, such as "node-instance-identifier", and > > then > > > > > > ietf-netconf-acm needn't be implemented (but can be), > > > > > > > > > > > > or > > > > > > > > > > > > - it augments ietf-netconf-acm, which makes sense only if the latter > > > > > > module is implemented. > > > > > > > > > > > > It it the YANG library that specifies whether a module is > > > > > > implemented or not, but the "import" statement itself doesn't tell > > you > > > > > > anything. > > > > > > > > > > > > > > > > Can we not assume that an implementor will figure out the difference? > > > > > > > > An implementor should be able to figure it out, but other potential > > > > module users may not. For example, if somebody is evaluating whether > > > > to use a module for their device or not, it is important to know that > > > > NACM has to be implemented (or not). > > > > > > > > > > > > > > > > You seem to be talking about a new conformance documentation procedure > > > > > > > > that attempts to solve the problem "to use modules A, B, and C > > > > together > > > > > > > > to achieve some functionality X, all these conditions need to be met".. > > > > > > > > (Sounds more like a problem for YANG Packages to solve) > > > > > > > > > > > > > > > > IMO this is a much harder problem than something that can be solved > > > > > > > > with extra description-stmt text. The writer is likely to get it wrong > > > > or not > > > > > > > > keep it up to date, so a tool to analyze the file seems like a better > > > > solution. > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > Or someone writes a pyang plugin to determine from the schema tree > > > > > the kind of imports there are (for a given set of features). > > > > > > > > > > /js > > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 8 10:41:39 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454F8120047 for ; Wed, 8 Jan 2020 10:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 dosVn_AW6ilh for ; Wed, 8 Jan 2020 10:41:33 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E44D120059 for ; Wed, 8 Jan 2020 10:41:33 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id m26so4348849ljc.13 for ; Wed, 08 Jan 2020 10:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dd7cPxT9GJSP7NDE+lN6idxY7+CZ0DL0ZK+VYEFYvp8=; b=TozJMpPTXEJnStTK4/ybMF+KMUgz9zsPlkZ707P6itNK8z9tFMfzM1+abfqHt/64da DmgGkGx5+1HWrdFoDhWQvJdevw/Kk0Dk4yyf9FxHqBbFlSSLHVoPhV07Eb3WjFXLyz1N 5rXEQCz72tdh9m7wf3lVU+0/6p+vaBm5LwffM0jr4ZmolsYz5iZAw90wGpY1z35FfMJ3 Aae0CDd2vTN4oABF7g7lrEAI3bKt+CmkFXke0ezLUW+UYpey5WxAQ5kGJQEUWThnFtfG XLKXhjtwzmYDFoZU88kAUEFRbarki64WIRhvJh8JyFMHaWfhUoIxfFGyPjWGuW4EeRfK mS+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dd7cPxT9GJSP7NDE+lN6idxY7+CZ0DL0ZK+VYEFYvp8=; b=f/azlDjihDojiP/vSPCQkzzlfkK9DO12Q95gl+mm032OKcdoggpM4Jxu/+PS2wLK3Q jOikbzuRJboi7aC5qaFweTOhuwY04Tm1QYrt98bg5a5OHgFJfUTHShpySCQQhayZ1qWl DhnVGaXNREaircLaeuuBq/aH9JxUtHHjc8YbfE/3zTnug9bW47wMmXh3X3qMQsfSqDva qCKAv13uyKKAl3Q0+n+Jkk1twbckt/WTZKhfuzfQg4evLIWtTrbzgyPXzsDqg34OObwt lsol8pIMJMXMxe8wOaqTMWAuQB59jScqcZqmYJO+XOtqGhbxgp+HAlq5C1H8iPxU8uFy WZ1Q== X-Gm-Message-State: APjAAAVPXq35S9f3TAThXCGVZSFLxy0wrs/g5YdoJXKDcT25w035hWE2 HeTyZtKc25pEm/O0CmqWcvIUlx/IPwyAAxGtRxkVyw== X-Google-Smtp-Source: APXvYqxY1JyG9CwY+qPijKq7BJ/04X4//3RjXGOZ5dY5sJxXWj7igpAQjKHJPdz5rKjIAyH/+/lxTo5DYILKumdcWh8= X-Received: by 2002:a2e:580c:: with SMTP id m12mr3820122ljb.252.1578508891256; Wed, 08 Jan 2020 10:41:31 -0800 (PST) MIME-Version: 1.0 References: <20200107.143818.1928135118621633911.mbj@tail-f.com> In-Reply-To: From: Andy Bierman Date: Wed, 8 Jan 2020 10:41:20 -0800 Message-ID: To: Ladislav Lhotka Cc: NETMOD WG Content-Type: multipart/alternative; boundary="000000000000bd1728059ba53d5e" Archived-At: Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:41:37 -0000 --000000000000bd1728059ba53d5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka wrote: > On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote: > > > > On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka wrote: > > > On Tue, 2020-01-07 at 14:29 +0000, Bal=C3=A1zs Lengyel wrote: > > > > If that is the consensus, I can remove the description statements, > no big > > > > deal. (I actually like the statements, but they are not important > for this > > > > draft) > > > > > > Of course, it is not that important, but I don't see how this > information > > > could > > > be harmful, if it is included with the import. In my view, it is not > meant > > > as a > > > conformance requirement but just an info from the module author about > the > > > meaning of the import statement. > > > > > > > It adds a lot of extra work but more importantly the import-stmt is the > wrong > > place > > What work do you mean? I thought that it would be just info for potential > developers (or their managers) that implementing the module requires > implementing other modules and functionality - or not. > > It is duplication because the individual data-def statements should have any notes about implementation requirements. The duplication may even be wrong. E.g., in the module it says NACM is not required, but what if some objects have NACM requirements listed in the Security Considerations section? That is the RFC section to discuss NACM requirements. For example, if a module imports ietf-netconf-nacm only for using "node- > instance-identifier" type, it is relatively uninteresting. Otherwise, > implementation of the module may just be out of question. > > > > to document such a complex and unrelated issue as server conformance > > requirements. > > > > > > > The root of this problem (and design flaw of YANG, IMO) is that impor= t > is > > > "overloaded" with two different purposes, one of which effectively > requires > > > that > > > the imported module be also implemented, while the other doesn't. > > > > > > > The import-stmt is only used to map a local prefix to an external modul= e. > > But one thing is using a prefix for accessing top-level types and groupin= gs > (i.e. stuff in YANG modules), and another thing is accessing schema nodes= , > which > have to be present in the schema tree. In complicated data models, it is > not > exactly easy to figure out all these dependencies. > > I do not agree these are different things. In both cases the prefix is used to determine the imported module that contains the identifier. So maybe what is really overloaded are the namespace prefixes: they are > used for > addressing YANG modules, schema nodes and instances (in XPath). > > Lada > Andy > > > This proposal to add conformance info the the import-stmt would overloa= d > it > > with > > another purpose. > > > > Not even a typedef is easy to classify (e.g., leafref requires > implementation > > of a data node). > > I certainly agree that YANG conformance is poorly specified, poorly > > understood, and > > in real need of improvement. Likewise, the import-stmt is also in need > of some > > improvement > > since import-by-exact-revision is (and has always been) poorly designed= . > > > > > > > Lada > > > > > > > Balazs > > > > Andy > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund > > > > Sent: Tuesday, January 7, 2020 2:38 PM > > > > To: Bal=C3=A1zs Lengyel > > > > Cc: andy@yumaworks.com; lhotka@nic.cz; netmod@ietf.org > > > > Subject: Re: [netmod] Text in import to indicate whether a module i= s > > > needed as > > > > import-only or as implemented > > > > > > > > Hi > > > > > > > > I agree w/ Andy and others that we should not add this to the > import's > > > > description. I don't think this kind of conformance text belongs t= o > the > > > > import's description. If you think it is important to state this, > the > > > best > > > > place is probably as plain text in the document itself. > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > Bal=C3=A1zs Lengyel wrote: > > > > > As a draft author who was asked to add text about the imports IMH= O > > > > > > > > > > * it would be easy for me to remove the description from the > import. > > > > > Actually I really just want to know what is acceptable to the > group, so > > > I > > > > > can proceed > > > > > * I also think that adding this text is in most cases easy and > it does > > > not > > > > > need updates later. > > > > > * The rules in some cases might not be trivial. > > > > > > > > > > * Imported YAMs need to be implemented if > > > > > > > > > > * Imported parts are included in Xpath (augment, when, must, > require- > > > > > instance) > > > > > > > > > > * Imported YAMs do not need to be implemented if only the > following > > > are > > > > > used > > > > > > > > > > * Types > > > > > * Features > > > > > * extensions > > > > > > > > > > * Ambiguous if > > > > > > > > > > * groupings are used > > > > > * if the dependency is not formally defined by YANG, but > functionally > > > > > needed. (E.g. notification-capabilities does not formally need > YANG- > > > > > Push > > > to > > > > > be implemented, however there is no sense in defining capabilitie= s > if > > > YANG- > > > > > Push is itself not implemented.) > > > > > * deviation ? > > > > > * other cases ? > > > > > > > > > > Regards Balazs > > > > > > > > > > > > > > > > > > > > From: netmod On Behalf Of Andy Bierman > > > > > Sent: 2019. december 19., cs=C3=BCt=C3=B6rt=C3=B6k 17:23 > > > > > To: Ladislav Lhotka > > > > > Cc: NetMod WG > > > > > Subject: Re: [netmod] Text in import to indicate whether a module > is > > > > > needed as import-only or as implemented > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka > > > > lhotka@nic.cz> > wrote: > > > > > > > > > > On Thu, 2019-12-19 at 07:52 +0000, Sch=C3=B6nw=C3=A4lder, J=C3=BC= rgen wrote: > > > > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote= : > > > > > > > I don't see how YANG syntax defines this. If a module imports > > > > > > > ietf-netconf- acm, it could be because > > > > > > > > > > > > > > - it just uses a typedef, such as "node-instance-identifier", > and > > > then > > > > > > > ietf-netconf-acm needn't be implemented (but can be), > > > > > > > > > > > > > > or > > > > > > > > > > > > > > - it augments ietf-netconf-acm, which makes sense only if the > latter > > > > > > > module is implemented. > > > > > > > > > > > > > > It it the YANG library that specifies whether a module is > > > > > > > implemented or not, but the "import" statement itself doesn't > tell > > > you > > > > > > > anything. > > > > > > > > > > > > > > > > > > > Can we not assume that an implementor will figure out the > difference? > > > > > > > > > > An implementor should be able to figure it out, but other > potential > > > > > module users may not. For example, if somebody is evaluating > whether > > > > > to use a module for their device or not, it is important to know > that > > > > > NACM has to be implemented (or not). > > > > > > > > > > > > > > > > > > > > You seem to be talking about a new conformance documentation > procedure > > > > > > > > > > that attempts to solve the problem "to use modules A, B, and C > > > > > together > > > > > > > > > > to achieve some functionality X, all these conditions need to be > met".. > > > > > > > > > > (Sounds more like a problem for YANG Packages to solve) > > > > > > > > > > > > > > > > > > > > IMO this is a much harder problem than something that can be solv= ed > > > > > > > > > > with extra description-stmt text. The writer is likely to get it > wrong > > > > > or not > > > > > > > > > > keep it up to date, so a tool to analyze the file seems like a > better > > > > > solution. > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > Or someone writes a pyang plugin to determine from the schema > tree > > > > > > the kind of imports there are (for a given set of features). > > > > > > > > > > > > /js > > > > > > > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000bd1728059ba53d5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Wed, 2020-01= -08 at 04:49 -0800, Andy Bierman wrote:
    >
    > On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
    > > On Tue, 2020-01-07 at 14:29 +0000, Bal=C3=A1zs Lengyel wrote:
    > > > If that is the consensus, I can remove the description state= ments, no big
    > > > deal. (I actually like the statements, but they are not impo= rtant for this
    > > > draft)
    > >
    > > Of course, it is not that important, but I don't see how this= information
    > > could
    > > be harmful, if it is included with the import. In my view, it is = not meant
    > > as a
    > > conformance requirement but just an info from the module author a= bout the
    > > meaning of the import statement.
    > >
    >
    > It adds a lot of extra work but more importantly the import-stmt is th= e wrong
    > place

    What work do you mean? I thought that it would be just info for potential developers (or their managers) that implementing the module requires
    implementing other modules and functionality - or not.



    It is duplication becau= se=C2=A0the individual data-def statements should have any notes
    = about implementation requirements. The duplication may even be wrong.
    =
    E.g., in the module it says NACM is not required, but what if some obj= ects
    have NACM requirements listed in the Security Considerations= section?
    That is the RFC section to discuss NACM requirements.


    For example, if a module imports ietf-netconf-nacm only for using "nod= e-
    instance-identifier" type, it is relatively uninteresting. Otherwise,<= br> implementation of the module may just be out of question.


    > to document such a complex and unrelated issue as server conformance > requirements.
    >
    >
    > > The root of this problem (and design flaw of YANG, IMO) is that i= mport is
    > > "overloaded" with two different purposes, one of which = effectively requires
    > > that
    > > the imported module be also implemented, while the other doesn= 9;t.
    > >
    >
    > The import-stmt is only used to map a local prefix to an external modu= le.

    But one thing is using a prefix for accessing top-level types and groupings=
    (i.e. stuff in YANG modules), and another thing is accessing schema nodes, = which
    have to be present in the schema tree. In complicated data models, it is no= t
    exactly easy to figure out all these dependencies.


    I do not agree these are different thi= ngs.
    In both cases the prefix is used to determine the imported m= odule that contains the identifier.


    So maybe what is really overloaded are the namespace prefixes: they are use= d for
    addressing YANG modules, schema nodes and instances (in XPath).

    Lada


    Andy
    =C2= =A0

    > This proposal to add conformance info the the import-stmt would overlo= ad it
    > with
    > another purpose.
    >
    > Not even a typedef is easy to classify=C2=A0 (e.g., leafref requires i= mplementation
    > of a data node).
    > I certainly agree that YANG conformance is poorly specified, poorly > understood, and
    > in real need of improvement. Likewise, the import-stmt is also in need= of some
    > improvement
    > since import-by-exact-revision is (and has always been) poorly designe= d.
    >
    >
    > > Lada
    > >
    > > > Balazs
    >
    > Andy
    >
    >=C2=A0
    > > > -----Original Message-----
    > > > From: Martin Bjorklund <mbj@tail-f.com>
    > > > Sent: Tuesday, January 7, 2020 2:38 PM
    > > > To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
    > > > Cc: = andy@yumaworks.com; = lhotka@nic.cz; net= mod@ietf.org
    > > > Subject: Re: [netmod] Text in import to indicate whether a m= odule is
    > > needed as
    > > > import-only or as implemented
    > > >
    > > > Hi
    > > >
    > > > I agree w/ Andy and others that we should not add this to th= e import's
    > > > description.=C2=A0 I don't think this kind of conformanc= e text belongs to the
    > > > import's description.=C2=A0 If you think it is important= to state this, the
    > > best
    > > > place is probably as plain text in the document itself.
    > > >
    > > >
    > > >
    > > > /martin
    > > >
    > > >
    > > > Bal=C3=A1zs Lengyel <balazs.lengyel=3D40ericsson.com@dmarc.ietf.o= rg> wrote:
    > > > > As a draft author who was asked to add text about the i= mports IMHO
    > > > >
    > > > > *=C2=A0 =C2=A0it would be easy for me to remove the des= cription from the import.
    > > > > Actually I really just want to know what is acceptable = to the group, so
    > > I
    > > > > can proceed
    > > > > *=C2=A0 =C2=A0I also think that adding this text is in = most cases easy and it does
    > > not
    > > > > need updates later.
    > > > > *=C2=A0 =C2=A0The rules in some cases might not be triv= ial.
    > > > >
    > > > > *=C2=A0 =C2=A0Imported YAMs need to be implemented if > > > >
    > > > > *=C2=A0 =C2=A0Imported parts are included in Xpath (aug= ment, when, must, require-
    > > > > instance)
    > > > >
    > > > > *=C2=A0 =C2=A0Imported YAMs do not need to be implement= ed if only the following
    > > are
    > > > > used
    > > > >
    > > > > *=C2=A0 =C2=A0Types
    > > > > *=C2=A0 =C2=A0Features
    > > > > *=C2=A0 =C2=A0extensions
    > > > >
    > > > > *=C2=A0 =C2=A0Ambiguous if
    > > > >
    > > > > *=C2=A0 =C2=A0groupings are used
    > > > > *=C2=A0 =C2=A0if the dependency is not formally defined= by YANG, but functionally
    > > > > needed. (E.g. notification-capabilities does not formal= ly need YANG-
    > > > > Push
    > > to
    > > > > be implemented, however there is no sense in defining c= apabilities if
    > > YANG-
    > > > > Push is itself not implemented.)
    > > > > *=C2=A0 =C2=A0deviation ?
    > > > > *=C2=A0 =C2=A0other cases ?
    > > > >
    > > > > Regards Balazs
    > > > >
    > > > >=C2=A0
    > > > >
    > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bi= erman
    > > > > Sent: 2019. december 19., cs=C3=BCt=C3=B6rt=C3=B6k 17:2= 3
    > > > > To: Ladislav Lhotka <lhotka@nic.cz>
    > > > > Cc: NetMod WG <netmod@ietf.org>
    > > > > Subject: Re: [netmod] Text in import to indicate whethe= r a module is
    > > > > needed as import-only or as implemented
    > > > >
    > > > >=C2=A0
    > > > >
    > > > >=C2=A0
    > > > >
    > > > >=C2=A0
    > > > >
    > > > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka <lhotka@nic.cz <mailt= o:
    > > > > lhot= ka@nic.cz> > wrote:
    > > > >
    > > > > On Thu, 2019-12-19 at 07:52 +0000, Sch=C3=B6nw=C3=A4lde= r, J=C3=BCrgen wrote:
    > > > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav= Lhotka wrote:
    > > > > > > I don't see how YANG syntax defines this.= If a module imports
    > > > > > > ietf-netconf- acm, it could be because
    > > > > > >
    > > > > > > - it just uses a typedef, such as "node-= instance-identifier", and
    > > then
    > > > > > >=C2=A0 =C2=A0ietf-netconf-acm needn't be i= mplemented (but can be),
    > > > > > >
    > > > > > > or
    > > > > > >
    > > > > > > - it augments ietf-netconf-acm, which makes s= ense only if the latter
    > > > > > >=C2=A0 =C2=A0module is implemented.
    > > > > > >
    > > > > > > It it the YANG library that specifies whether= a module is
    > > > > > > implemented or not, but the "import"= ; statement itself doesn't tell
    > > you
    > > > > > > anything.
    > > > > > >
    > > > > >
    > > > > > Can we not assume that an implementor will figure = out the difference?
    > > > >
    > > > > An implementor should be able to figure it out, but oth= er potential
    > > > > module users may not. For example, if somebody is evalu= ating whether
    > > > > to use a module for their device or not, it is importan= t to know that
    > > > > NACM has to be implemented (or not).
    > > > >
    > > > >=C2=A0
    > > > >
    > > > > You seem to be talking about a new conformance document= ation procedure
    > > > >
    > > > > that attempts to solve the problem "to use modules= A, B, and C
    > > > > together
    > > > >
    > > > > to achieve some functionality X, all these conditions n= eed to be met"..
    > > > >
    > > > > (Sounds more like a problem for YANG Packages to solve)=
    > > > >
    > > > >=C2=A0
    > > > >
    > > > > IMO this is a much harder problem than something that c= an be solved
    > > > >
    > > > > with extra description-stmt text. The writer is likely = to get it wrong
    > > > > or not
    > > > >
    > > > > keep it up to date, so a tool to analyze the file seems= like a better
    > > > > solution.
    > > > >
    > > > >=C2=A0
    > > > >
    > > > > Lada
    > > > >
    > > > >=C2=A0
    > > > >
    > > > >=C2=A0
    > > > >
    > > > > Andy
    > > > >
    > > > >=C2=A0
    > > > >
    > > > >
    > > > > > Or someone writes a pyang plugin to determine from= the schema tree
    > > > > > the kind of imports there are (for a given set of = features).
    > > > > >
    > > > > > /js
    > > > > >
    > > > > --
    > > > > Ladislav Lhotka
    > > > > Head, CZ.NIC Labs
    > > > > PGP Key ID: 0xB8F92B08A9F76C67
    > > > >
    > > > > _______________________________________________
    > > > > netmod mailing list
    > > > > ne= tmod@ietf.org <mailto:netmod@ietf.org>
    > > > > https://www.ietf.org/mailman/listinf= o/netmod
    > > > >
    --
    Ladislav Lhotka
    Head, CZ.NIC Labs
    PGP Key ID: 0xB8F92B08A9F76C67

    _______________________________________________
    netmod mailing list
    netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
    --000000000000bd1728059ba53d5e-- From nobody Thu Jan 9 15:28:35 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFF412003E; Thu, 9 Jan 2020 15:28:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157861251031.11821.9719140738474484600.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2020 15:28:30 -0800 Archived-At: Subject: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 23:28:30 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-artwork-folding-11: 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-netmod-artwork-folding/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the updates in the -10 and -11; the content looks a lot better and I am not uncomfortable about publishing as Informational (vs. BCP)! That said, I think the edits to the script have introduced a regression: # ensure input file doesn't contain the fold-sequence already if [[ -n "$("$SED" -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' "$infile")" ]] Unfortunately, I'm not sure this gets all cases, since the 'N' command reads a line and prevents it from being considered as the first half of the wrapped sequence: kaduk$:~/git/openssl$ cat /tmp/a this is a line\ another line\ \that wraps kaduk$:~/git/openssl$ cat /tmp/b this is a line another line\ \that wraps kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/a kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/b another line\ \that wraps ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few other comments from reviewing the version of the script in the -11: When processing input, it's perhaps more robust to check $# before assigning $2 to a named parameter. printf "Exit status code: 1 on error, 0 on success, 255 on no-op." Interesting to have no newline here but two on the next line's printf, but I guess it might be at the column limit already. (The quotes on 'Error'/'Warning'/'Debug' in err()/warn()/dbg() are noops.) # warn if a non-GNU sed utility is used "$SED" --version < /dev/null 2> /dev/null \ | grep GNU > /dev/null 2>&1 || \ `grep -q` should be usable instead of `grep >/dev/null` From nobody Sat Jan 11 06:25:19 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E212008F; Sat, 11 Jan 2020 06:25:17 -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, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 r9hi7S4vR9Ca; Sat, 11 Jan 2020 06:25:14 -0800 (PST) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 B58E3120045; Sat, 11 Jan 2020 06:25:14 -0800 (PST) Received: from [172.20.10.2] (x2e720344.dyn.telefonica.de [46.114.3.68] (may be forged)) (authenticated bits=0) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 00BEOxai109513 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Jan 2020 15:25:09 +0100 To: Benjamin Kaduk , The IESG Cc: draft-ietf-netmod-artwork-folding@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <157861251031.11821.9719140738474484600.idtracker@ietfa.amsl.com> From: Erik Auerswald Message-ID: <597a69b9-a7ec-6b63-65e1-0c64d63574f5@unix-ag.uni-kl.de> Date: Sat, 11 Jan 2020 15:24:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157861251031.11821.9719140738474484600.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 14:25:17 -0000 Hello Benjamin, On 10.01.20 00:28, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-netmod-artwork-folding-11: 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-netmod-artwork-folding/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the updates in the -10 and -11; the content looks a lot better and > I am not uncomfortable about publishing as Informational (vs. BCP)! Thanks for the review. :-) > That said, I think the edits to the script have introduced a regression: > > # ensure input file doesn't contain the fold-sequence already > if [[ -n "$("$SED" -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' "$infile")" ]] > > Unfortunately, I'm not sure this gets all cases, since the 'N' command > reads a line and prevents it from being considered as the first half of the > wrapped sequence: > > kaduk$:~/git/openssl$ cat /tmp/a > this is a line\ > another line\ > \that wraps > kaduk$:~/git/openssl$ cat /tmp/b > this is a line > another line\ > \that wraps > kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/a > kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/b > another line\ > \that wraps Thanks for the bug report complete with test cases and analysis. :-) The fix should be adding ";D" to the sed script: sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p;D}' I'll look into adding this (with tests) soon. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A few other comments from reviewing the version of the script in the -11: > > When processing input, it's perhaps more robust to check $# before assigning $2 > to a named parameter. That sounds reasonable. > printf "Exit status code: 1 on error, 0 on success, 255 on no-op." > > Interesting to have no newline here but two on the next line's printf, but I > guess it might be at the column limit already. Exactly. > (The quotes on 'Error'/'Warning'/'Debug' in err()/warn()/dbg() are noops.) They improve syntax-highlighting results in vim. ;-) > # warn if a non-GNU sed utility is used > "$SED" --version < /dev/null 2> /dev/null \ > | grep GNU > /dev/null 2>&1 || \ > > `grep -q` should be usable instead of `grep >/dev/null` I intend to change this to use `grep -q`. Thanks, Erik From nobody Sun Jan 12 11:04:36 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F02120013; Sun, 12 Jan 2020 11:04:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netmod-chairs@ietf.org, ibagdona@gmail.com, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157885587509.23375.14110800997655980756.idtracker@ietfa.amsl.com> Date: Sun, 12 Jan 2020 11:04:35 -0800 Archived-At: Subject: [netmod] netmod - New Meeting Session Request for IETF 107 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 19:04:35 -0000 A new meeting session request has just been submitted by Joel Jaeggli, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Joel Jaeggli Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: netconf Technology Overlap: rtgwg i2rs teas Key Participant Conflict: saag People who must be present: Lou Berger Joel Jaeggli Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jan 12 11:08:42 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F60120044; Sun, 12 Jan 2020 11:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8KgYvMOg0dtD; Sun, 12 Jan 2020 11:08:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 CA879120013; Sun, 12 Jan 2020 11:08:39 -0800 (PST) Received: from mb.local (50-242-125-195-static.hfc.comcastbusiness.net [50.242.125.195]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id 00CJ8cTj072472; Sun, 12 Jan 2020 19:08:38 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host 50-242-125-195-static.hfc.comcastbusiness.net [50.242.125.195] claimed to be mb.local To: netmod-chairs@ietf.org Cc: ibagdona@gmail.com, joelja@gmail.com, netmod@ietf.org References: <157885587509.23375.14110800997655980756.idtracker@ietfa.amsl.com> From: joel jaeggli Openpgp: preference=signencrypt Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= mQGiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfmrQfSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiauQQNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8GIRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: <2e337fe6-5890-8a49-00a3-54552c42ba65@bogus.com> Date: Sun, 12 Jan 2020 11:08:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <157885587509.23375.14110800997655980756.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cJ3MrPShxSMXFkISRKhCspOeyIJ3yeC5G" Archived-At: Subject: Re: [netmod] netmod - New Meeting Session Request for IETF 107 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 19:08:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cJ3MrPShxSMXFkISRKhCspOeyIJ3yeC5G Content-Type: multipart/mixed; boundary="Cy4aN4777fIyMYR42qBVpgIKaSgNb2FrO"; protected-headers="v1" From: joel jaeggli To: netmod-chairs@ietf.org Cc: ibagdona@gmail.com, joelja@gmail.com, netmod@ietf.org Message-ID: <2e337fe6-5890-8a49-00a3-54552c42ba65@bogus.com> Subject: Re: netmod - New Meeting Session Request for IETF 107 References: <157885587509.23375.14110800997655980756.idtracker@ietfa.amsl.com> In-Reply-To: <157885587509.23375.14110800997655980756.idtracker@ietfa.amsl.com> --Cy4aN4777fIyMYR42qBVpgIKaSgNb2FrO Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable fyi, made this request based on the last one. On 1/12/20 11:04, IETF Meeting Session Request Tool wrote: >=20 >=20 > A new meeting session request has just been submitted by Joel Jaeggli, = a Chair of the netmod working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Network Modeling > Area Name: Operations and Management Area > Session Requester: Joel Jaeggli >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 1 Hour > Number of Attendees: 100 > Conflicts to Avoid:=20 > Chair Conflict: netconf > Technology Overlap: rtgwg i2rs teas > Key Participant Conflict: saag >=20 >=20 > People who must be present: > Lou Berger > Joel Jaeggli > Kent Watsen > Ignas Bagdonas >=20 > Resources Requested: >=20 > Special Requests: > =20 > --------------------------------------------------------- >=20 --Cy4aN4777fIyMYR42qBVpgIKaSgNb2FrO-- --cJ3MrPShxSMXFkISRKhCspOeyIJ3yeC5G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCXhtutQAKCRDwADWrtn9W sgZjAJ9NJ1/ktm6YQFsb1yL5x8Ae/GXO7gCeIrFFi4HUGYiCB41zMns5Jq/+GxQ= =U14V -----END PGP SIGNATURE----- --cJ3MrPShxSMXFkISRKhCspOeyIJ3yeC5G-- From nobody Mon Jan 20 06:45:43 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072451200B7 for ; Mon, 20 Jan 2020 06:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 bFJkZ3_OHOIo for ; Mon, 20 Jan 2020 06:45:34 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40080.outbound.protection.outlook.com [40.107.4.80]) (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 1F572120041 for ; Mon, 20 Jan 2020 06:45:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n46ZGOeZu/7pL6OIDWSQpVaq65f6RWT4SMwrrru91vJOYhKwLM2VR9jNniKy3wU1KyhI1s1QlO5ZZ78IuWp6/l530p79xjn0D6t7pj4ONKwj5OrZo68s5NUz8zqN1Ym8edEyNOQ+lbEHhfj5sC0M8nwx0B8TJJObbbH+OaKTVwc1oyCFL7OjvNWRIiq/Sxkk+oZcrscQ/s+1S47Z2JS6u4SdXsgak/+rs/sMWSnvqLyo0cFHhj/OzZ5q//SoeDalX+vRZQc2z4NRlK3ai4hVEhzrQisgzLUTgzDdL48dXPnhiak6mrTaDmvdXKJF0ii637IK3YncCE3Uz2o9bjYxqQ== 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=C6xVE4AZMd4ViBtDKgMDSHX/Jk+4GN9rV1qkgxj/RFU=; b=MdhrmIadau3mnV7rJHmkqHwgwFuHk6rNJeQEOq9XUkuxMDLBZY5Rq8s06h+/ZmnXZNWU974bVIQNe8dJNe1HLkkYtlmY6VDhrulgNe68yuD6z2XXIokCUT0WvTUdwqAjpyv1ZLVgsmmkK23s+QkPe+BwBnK7P+7tKP8SyG5UihVCHMlUprQDEeAy7XniHSxL4HL6+4yldasyAmun8JmTiVeHKE0NpNIaG6mLkVVWE95lHeq73bkeninCNQT3UYlsG6x6NvkqClh6c39Wqe8Ma3uB/kE8f8XfdCe1LuT0sGKTMV/RhDGYO8nN4FHNU58EexSGVUlazql2R3UPkUrTSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6xVE4AZMd4ViBtDKgMDSHX/Jk+4GN9rV1qkgxj/RFU=; b=gxVP473Rc9odBpZlpausCR7GotFWX6XhxD+nBScyKsAWfSpECEd3kSXjnPUPMvQmbkrRmj1cnay1vcODq4VWJJGpqvBSHsIVnxFs9FJKKDaCMwF2A3Th884Ob+peAJ7selrAI2TUaaDzVCfanpbF4Ruu4A7VoJuklR2B2v2MT5c= Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0117.EURP190.PROD.OUTLOOK.COM (10.172.228.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Mon, 20 Jan 2020 14:45:30 +0000 Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946%6]) with mapi id 15.20.2644.024; Mon, 20 Jan 2020 14:45:30 +0000 Received: from localhost (2001:638:709:5::7) by ZR0P278CA0002.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19 via Frontend Transport; Mon, 20 Jan 2020 14:45:29 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: NETMOD Working Group Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 Thread-Index: AQHVxVfQ4dtefa62LU22UA5i1BqLNafztdMA Date: Mon, 20 Jan 2020 14:45:30 +0000 Message-ID: <20200120144528.wt2z4y66xcnp7fxj@anna.jacobs.jacobs-university.de> References: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@email.amazonses.com> In-Reply-To: <0100016f8006222d-b861a109-93ee-4a77-8b65-54c22d591e25-000000@email.amazonses.com> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: ZR0P278CA0002.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::12) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e314c24-dbb5-4c9c-dd09-08d79db76551 x-ms-traffictypediagnostic: DB6P190MB0117: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(376002)(136003)(39850400004)(199004)(189003)(2906002)(478600001)(4326008)(6666004)(8676002)(186003)(16526019)(81166006)(81156014)(1076003)(3450700001)(52116002)(71200400001)(786003)(5660300002)(316002)(8936002)(66476007)(66556008)(64756008)(6486002)(66446008)(6496006)(66946007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0117; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XPVefVJLpoXyhN8CZu6TqHsMl/TkbRAbB03H1zkqcFtqz5BkgaPE8HMEJqBXWEb2aGAycQ4yICLgBDFngDnql+hFPEKz0wHNUCtoxqqUNJQv4IYA8KGSssOroO63427jQhwxln+mjQJnf8H/iqN3YEsuMJDIsheoEw7dMLXFihGISwqj6g0bCSl3LESKFoWIh00vx+x/JDTuXhphsQCIJT9pKkkjLOG4Q0+x9e7rakeegMX451jjqWVsgR6ilZ5LiIl+px1JDuonMiES9yoH5OX9eF+3us01Q0CHUl3HT4EXRdkszeCsZPiF1nQJlEvj6B6HNdp0HDWURyuyjcGHotekKqKDSFNNPlqpOe+Pxhj75/LWT2nrMLGSzIVpFhwaIrh4Qev9tX+zygjGSGS74m5vEZ2AFRXEamDG+uiVwH8143WVPLdT+QnGBHbBU0/JH5Qwo3l3kjK88ZzgofGn2HZTc/U4usNPFoRFGKPizK0yfqhEptFScdMFQR0DVv+0RZ4PbMXElWCs/XIuoEqEIw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1F6A024F87B2B343AE6A4F9EEB312583@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 3e314c24-dbb5-4c9c-dd09-08d79db76551 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2020 14:45:30.3762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 42WzG1NlADBTWGf0JauT9VDifooTxiJfCH9mh4f9xxwN1Bybs+jjJaXxvHcXEkoWGU5AjA6CQZU3bCGXtPkoMWwsK2uQ3Tli4y446xBXtPs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0117 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 14:45:41 -0000 On Tue, Jan 07, 2020 at 12:41:23PM +0000, Kent Watsen wrote: >=20 > This begins a two-week Working Group Last Call (WGLC) on draft-ietf-netmo= d-yang-instance-file-format-06. The WGLC ends on Jan 21. Please send your= comments to the working group mailing list. >=20 > Positive comments, e.g., "I've reviewed this document and believe it is r= eady for publication", are welcome! This is useful and important, even fro= m authors. Objections, concerns, and suggestions are also welcomed at this= time. > I have reviewed draft-ietf-netmod-yang-instance-file-format-06. I believe this is an important document but not quite ready yet. Most of the points I am raising below should, however, be easy to resolve, many concern terminology and writing consolidation and do not affect the technical solution. /js * Abstract I think we should avoid referring to some operation. Here is a proposal of a rewrite: OLD running server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the reply to a operation/request) and annotates it with metadata. NEW running server available. This document specifies a standard file format for YANG instance data, which follows the syntax and semantic of existing YANG models, and annotates it with metadata. * Terminology - Add missing dots (full stops) at the end of sentences - I fail to see the difference between 'content-schema' and 'content defining YANG module(s)'. The 'content-schema' is already a set of YANG modules. I suggest to remove 'Content defining YANG module(s) as it is not a necessary term. Rewrite all places where the phrase 'content defining YANG modules' is used. - Is "YANG Instance Data" a newly defined term? It's introduction does not follow the colon style. I also wonder why we need this term. Why is YANG in there? I would prefer to have this defined in RFC 7950 terms. Is 'instance data' a collection of instantiated 'data nodes'? Perhaps then we should do the following and move this up to the first definition, so we define instance data first, then instance data set, and finally instance data file. OLD YANG Instance Data, or just instance data for short, is data that could be stored in a datastore and whose syntax and semantics is defined by YANG models. NEW Instance Data: A collection of instantiated data nodes. * Introduction - It seems UC5 subsumes UC4. - One could add UCx: Storing instance data used as test cases but then this list of use cases does not need to be exhaustive (means I do not care much). - Is it necessary to describe P2 in terms of (presumably) NETCONF operations? I would prefer to have the document written in a protocol agnostic style. Perhaps simply drop "similar to the response of a operation/request". - P4: What is 'many'? Or did you want to use 'multiple'? * Instance Data File Format - Replace "real data" with instance data OLD "real data" that we want to document/provide. NEW instance data that we want to document/provide. - I do not understand that text about the default attribute. Section 4.8.9 defines a query parameter, not an attribute. And I do not know how that fits into content data. - Similarly, I do not understand why implementation specific metadata may be included in the content-data. This seems to be the wrong place, no? Should metadata not go into the header? - Why MUST XML attributes be ignored, why is there no text about unknown JSON data, 'attributes' (or annotations)? What should implementations generally do about unknown elements, attributes, objects, arrays, ...)? Why are we specific about only one specific case? - References may be helpful in this sentence since is not part of the original NETCONF specification: The content-data part will be very similar to the result returned for a NETCONF or for a RESTCONF get operation. It is unclear what "will be very similar" really means but perhaps this is clarified later. If not, this sentence says nothing in terms of a technical specification. - Does the following sentence imply that any additional data in an instance file renders the instance file useless? The content-data part MUST conform to the content-schema. - You first write that instance data MUST conform to the schema and two paragraphs later you state that instance data MAY be partial, i.e., it MAY NOT conform to the content-schema. Perhaps I have an idea what you wanted to say but the text that is written here is a contradiction. - The introduction contains several MAYs and MUSTS that are not understandable yet and they do not seem to belong into an 'Introduction' in the first place. - Why is EXTERNAL in all caps but Inline in capitalized form? In the YANG definitions, EXTERNAL seems to be uri. I think we reduce ambiguity by being consistent with how we name things. - What is a 'real-life YANG module'? - 3.1.1 How are the details specified in the anydata? Perhaps a forward reference might help. What are 'version labels'? - 3.1.2 What is a 'list of content'? Which revision is used? What about these 'version labels' here? - 3.2 I do not understand the example. Has this been validated? As far as I can tell, the ietf-yang-library defines modules-state and not module-state. This inconsistency shows up multiple times. - I like to understand why we need several methods to specify the schema. Having N solution is always bad for interoperability and also for maintainability. Perhaps the WG failed to reach consensus on a single solution. Or there are strong technical reasons - but then they should be clearly stated. What are implementations expected to support, all methods? Or whatever the implementer prefers? How do we achieve interoperability across tools? * Data Life Cycle - I am not sure the first paragraph is needed. - In the second paragraph, I like to see some discussion of snapshot consistency. How much consistency can be expected? Are there indicators for the level of consistency? I would remove the sentence about "valid values can be retrieved at run-time" as this is obvious but then I am not sure why 'valid' values? Perhaps the authors meant 'current' values? - How do I implement the "SHOULD be described"? The default is that data can change, only in rare cases data is static. But how does a tool creating instance data know 'when and how' data changes in the future? I suggest to remove the SHOULD. The text saying that instance data is a snapshot is in my view sufficient. - This section talks about YANG instance data but it likely should talk about YANG instance data sets. * Delivery of Instance Data - Why do we need this SHOULD? I do not think we should use RFC 2119 keywords to define how organizations may use the instance data format. My proposal is to delete this entire section. * Backwards Compatibility - I do not think 'managed entity' is a YANG term. - I think this text is use case specific and the items are kind of conflicting with each other (2nd says changing the semantics of a list should lead to a change of the key while the 1st suggests that changing keys may lead to misinterpretation of something being new). - My proposal is to simply drop this entire section. If use case specific text is needed, add it to the use cases in the appendix. * YANG Model - How is the inline-content-schema feature used? Which component does indicate that inline content-schema is supported? Do all implementations have to support simplified-inline? If inline-schema is used, how do I find out which schema formats are supported? The more formats there are, the more interoperability issues will arise. * Security Considerations - "is designed as a wrapper" - what does this tell me? I suggest to rewrite the first paragraph and to remove this phrase or to explain what it means. - Why is the header part not security sensitive? Almost all data is security sensitive in certain situations. - I would prefer if the text would not use the phrase "result of a operation". As stated before, I like to see things written in protocol neutral forms. - Since instance data files may require protection, is there any recommendation how to do this, e.g., by wrapping everything into a cryptographic message syntax or so? It would be important in certain use cases to be able to verify that instance data is authentic (i.e., it is signed by the original source). In other cases, it may be crucial to protect the instance data itself against occasional readers. - It may be useful to explain that data in instance data sets may have been filtered by access control rules like NACM and that data in instance data sets itself won't be filtered anymore by access control rules like NACM. In other words, if I take snapshots and stored them as instance data files, these snapshots may leak information that is otherwise protected. Hence it is important that NACM rules and file access control rules are consistent. --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 20 16:54:53 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC37120801; Mon, 20 Jan 2020 16:54:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <157956808666.1648.2901265393172966356@ietfa.amsl.com> Date: Mon, 20 Jan 2020 16:54:46 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 00:54:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Handling Long Lines in Inclusions in Internet-Drafts and RFCs Authors : Kent Watsen Erik Auerswald Adrian Farrel Qin Wu Filename : draft-ietf-netmod-artwork-folding-12.txt Pages : 30 Date : 2020-01-20 Abstract: This document defines two strategies for handling long lines in width-bounded text content. One strategy is based on the historical use of a single backslash ('\') character to indicate where line- folding has occurred, with the continuation occurring with the first non-space (' ') character on the next line. The second strategy extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 20 17:05:55 2020 Return-Path: <0100016fc5a2305d-ea9d8ddb-cbb4-43dd-a784-312903f199c0-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB56120835; Mon, 20 Jan 2020 17:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 87p70Qpqn8RZ; Mon, 20 Jan 2020 17:05:41 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F0F120801; Mon, 20 Jan 2020 17:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1579568739; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dTt7RGJb2QReGf8wS/iur8pd/gVHS9YRv4Pp1dfARFM=; b=bNq2MZ+ucCQk4kvVRuzoPQNtivnV/BAnRWF8Hub05iyuivnh4OlEX2D/t+Ml5kU7 13sHOIghlYDlr4BWHBM2SGDFV2yLjQIARecG7RK3x094vhI4EaioWtu0Rqyu52hgsDo SmBydMIMuj5KfN1la4k8KOTKfQjLnKY6spis+WPg= From: Kent Watsen Message-ID: <0100016fc5a2305d-ea9d8ddb-cbb4-43dd-a784-312903f199c0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_76749EF8-1604-4A76-8B9F-C59F2B8A161C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 Jan 2020 01:05:38 +0000 In-Reply-To: <597a69b9-a7ec-6b63-65e1-0c64d63574f5@unix-ag.uni-kl.de> Cc: The IESG , "netmod-chairs@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org To: Benjamin Kaduk References: <157861251031.11821.9719140738474484600.idtracker@ietfa.amsl.com> <597a69b9-a7ec-6b63-65e1-0c64d63574f5@unix-ag.uni-kl.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.21-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 01:05:46 -0000 --Apple-Mail=_76749EF8-1604-4A76-8B9F-C59F2B8A161C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ben, Erik and I addressed the regression issue raised below, and made a few = other minor improvements to the non-normative `rfcfold` script. Here is a direct link to the diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-artwork-folding-12= .txt = Please let us know if there are anymore improvements to be made. Thanks! Kent (and Erik) > On Jan 11, 2020, at 9:24 AM, Erik Auerswald = wrote: >=20 > Hello Benjamin, >=20 > On 10.01.20 00:28, Benjamin Kaduk via Datatracker wrote: >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-netmod-artwork-folding-11: 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-netmod-artwork-folding/ >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >> Thank you for the updates in the -10 and -11; the content looks a lot = better and >> I am not uncomfortable about publishing as Informational (vs. BCP)! >=20 > Thanks for the review. :-) >=20 >> That said, I think the edits to the script have introduced a = regression: >> # ensure input file doesn't contain the fold-sequence already >> if [[ -n "$("$SED" -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' "$infile")" ]] >> Unfortunately, I'm not sure this gets all cases, since the 'N' = command >> reads a line and prevents it from being considered as the first half = of the >> wrapped sequence: >> kaduk$:~/git/openssl$ cat /tmp/a >> this is a line\ >> another line\ >> \that wraps >> kaduk$:~/git/openssl$ cat /tmp/b >> this is a line >> another line\ >> \that wraps >> kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/a >> kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/b >> another line\ >> \that wraps >=20 > Thanks for the bug report complete with test cases and analysis. :-) > The fix should be adding ";D" to the sed script: >=20 > sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p;D}' >=20 > I'll look into adding this (with tests) soon. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >> A few other comments from reviewing the version of the script in the = -11: >> When processing input, it's perhaps more robust to check $# before = assigning $2 >> to a named parameter. >=20 > That sounds reasonable. >=20 >> printf "Exit status code: 1 on error, 0 on success, 255 on = no-op." >> Interesting to have no newline here but two on the next line's = printf, but I >> guess it might be at the column limit already. >=20 > Exactly. >=20 >> (The quotes on 'Error'/'Warning'/'Debug' in err()/warn()/dbg() are = noops.) >=20 > They improve syntax-highlighting results in vim. ;-) >=20 >> # warn if a non-GNU sed utility is used >> "$SED" --version < /dev/null 2> /dev/null \ >> | grep GNU > /dev/null 2>&1 || \ >> `grep -q` should be usable instead of `grep >/dev/null` >=20 > I intend to change this to use `grep -q`. >=20 > Thanks, > Erik >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_76749EF8-1604-4A76-8B9F-C59F2B8A161C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Ben,

    Erik and I = addressed the regression issue raised below, and made a few other minor = improvements to the non-normative `rfcfold` script.


    Please let us know if there are anymore improvements to be = made.

    Thanks!
    Kent (and Erik)



    On Jan = 11, 2020, at 9:24 AM, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:

    Hello = Benjamin,

    On 10.01.20 00:28, Benjamin Kaduk = via Datatracker wrote:
    Benjamin Kaduk has entered the following ballot position = for
    draft-ietf-netmod-artwork-folding-11: 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.htmlfor 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-netmod-artwork-fold= ing/
    ---------------------------------------------------------------= -------
    DISCUSS:
    ---------------------------------------------------------------= -------
    Thank you for the updates in the -10 and -11; the = content looks a lot better and
    I am not uncomfortable = about publishing as Informational (vs. BCP)!

    Thanks for the review. :-)

    That = said, I think the edits to the script have introduced a regression:
         # ensure input file doesn't = contain the fold-sequence already
    =      if [[ -n "$("$SED" -n '/\\$/{N;s/\\\n[ = ]*\\/&/p}' "$infile")" ]]
    Unfortunately, I'm not sure = this gets all cases, since the 'N' command
    reads a line = and prevents it from being considered as the first half of the
    wrapped sequence:
    kaduk$:~/git/openssl$ cat = /tmp/a
    this is a line\
    another line\
    \that wraps
    kaduk$:~/git/openssl$ cat /tmp/b
    this is a line
    another line\
    \that = wraps
    kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ = ]*\\/&/p}' < /tmp/a
    kaduk$:~/git/openssl$ sed -n = '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/b
    another = line\
    \that wraps

    Thanks for the bug report complete with test cases and = analysis. :-)
    The fix should be adding ";D" to the sed = script:

       sed -n = '/\\$/{N;s/\\\n[ ]*\\/&/p;D}'

    I'll look = into adding this (with tests) soon.

    ---------------------------------------------------------------= -------
    COMMENT:
    ---------------------------------------------------------------= -------
    A few other comments from reviewing the version of = the script in the -11:
    When processing input, it's perhaps = more robust to check $# before assigning $2
    to a named = parameter.

    That sounds = reasonable.

         printf "Exit status code: 1 on = error, 0 on success, 255 on no-op."
    Interesting to have no = newline here but two on the next line's printf, but I
    guess = it might be at the column limit already.

    Exactly.

    (The quotes on 'Error'/'Warning'/'Debug' in = err()/warn()/dbg() are noops.)

    They improve syntax-highlighting results in vim. ;-)

    =    # warn if a non-GNU sed utility is used
    =    "$SED" --version < /dev/null 2> /dev/null \
       | grep GNU > /dev/null 2>&1 || = \
    `grep -q` should be usable instead of `grep = >/dev/null`

    I intend to = change this to use `grep -q`.

    Thanks,
    Erik

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod

    = --Apple-Mail=_76749EF8-1604-4A76-8B9F-C59F2B8A161C-- From nobody Mon Jan 20 18:30:26 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758FA12006E; Mon, 20 Jan 2020 18:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=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 4YksUHc8V7oK; Mon, 20 Jan 2020 18:30:17 -0800 (PST) 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 7629112006D; Mon, 20 Jan 2020 18:30:17 -0800 (PST) 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 00L2UCmS009952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jan 2020 21:30:15 -0500 Date: Mon, 20 Jan 2020 18:30:12 -0800 From: Benjamin Kaduk To: Kent Watsen Cc: The IESG , "netmod-chairs@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org Message-ID: <20200121023012.GC80030@kduck.mit.edu> References: <157861251031.11821.9719140738474484600.idtracker@ietfa.amsl.com> <597a69b9-a7ec-6b63-65e1-0c64d63574f5@unix-ag.uni-kl.de> <0100016fc5a2305d-ea9d8ddb-cbb4-43dd-a784-312903f199c0-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0100016fc5a2305d-ea9d8ddb-cbb4-43dd-a784-312903f199c0-000000@email.amazonses.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 02:30:19 -0000 Hi Kent! On Tue, Jan 21, 2020 at 01:05:38AM +0000, Kent Watsen wrote: > Hi Ben, > > Erik and I addressed the regression issue raised below, and made a few other minor improvements to the non-normative `rfcfold` script. > > Here is a direct link to the diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-12.txt > > Please let us know if there are anymore improvements to be made. > > Thanks! > Kent (and Erik) I don't see any further improvements; this looks really nice now. (I assume Erik was consulted about the Acknowledgments change (and trust the RFC Editor to spell "Acknowledgments" according to house style) that's also part of the -12.) I'm updating my position in the datatracker now. -Ben From nobody Tue Jan 21 15:25:58 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A45212004E; Tue, 21 Jan 2020 15:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 YZHexVvrRV1P; Tue, 21 Jan 2020 15:25:52 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E2D12002E; Tue, 21 Jan 2020 15:25:52 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id p23so435149plq.10; Tue, 21 Jan 2020 15:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=hThdqzZ8cKL1R0lp8t9bTSD/R5bkNeYk97eFBBjIvP0=; b=mS6PC8VX8xaTKOoRpmJpUyMpQt0vcG9iVcVj/ytC2SBS6wOizMwPC/bessFhi72x5c 5usmqBRbzqoAgg+gaSrh07H6NfZbOvUKqlx6KAWqc4fvJyTJ8yCsb1sR5yz8h5HKPb3C RSu1ni3Y01zgzER0y0DvvsYBMOH2KazUSGFypdc/3J9TYiSQaCFq6PgbAE52bubHVrFb VZGQkcGJNH/12KhV8ystc+y1lUsF/4cKKWmluuDyd/r7IgC/10DQBcVdqswIe4LzCId9 EsVSfHvn9SuZO0VvLOQkMAo6ETswJKlC0/QA/wPLNc1jzbk1ZIKDBER+ODK1bY1PMMv1 o59g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=hThdqzZ8cKL1R0lp8t9bTSD/R5bkNeYk97eFBBjIvP0=; b=RifS4EXu0JpIDNUf4uarg3sDdnWj9ogPFtw3R0Aif2s6LxqvBqQ8CJx+93Nt66v2mI FbS3W1v4TvvomWbuSSsXYsTlR/AvbUS2HC0Z/XcBXCKs/+oTpqgWMTUvLb/kVPUBqSIt /pOWvfZwJguWRbVfgsVojrbHoQ3ddMGyKy1vM3k2QoWilME3Bw462H4clQ3AVNMXfFGz kHOjRx9YAm4pJdTCWMK9wX8Cv3qdbW/0c38w5B+TFtyyig01guZeDwcswouM5zt0x6LA k6NMBCuFVnHAvdCMYN/ogdpk0h2keSc6LBfJOTAbLoD4vThOoOgFHOuR72XvdYdclLJN 25lw== X-Gm-Message-State: APjAAAXGSbW7RET00pogUx4E6JdiqR2kEgU2y8AQifX8yxV/sm9q+MM3 6E5zUYWRc1ncy0uCc+4sdXpMOXbO X-Google-Smtp-Source: APXvYqx9cGfH5EcHyfMcKpZj5KtTPo+t4i/pjZYVxCdOzs39SvsjF0O76bJtCj+pcXQkgJujym2WkA== X-Received: by 2002:a17:90a:8001:: with SMTP id b1mr991580pjn.39.1579649150409; Tue, 21 Jan 2020 15:25:50 -0800 (PST) Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id i68sm45534956pfe.173.2020.01.21.15.25.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 15:25:49 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_81FBEBBD-4BC6-40EB-83F6-09AA84BB1F97" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 21 Jan 2020 15:25:48 -0800 Cc: draft-ietf-idr-bgp-model@ietf.org, Jeffrey Haas , Jeffrey Haas To: netmod X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netmod] Schema mount and Network Instance model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 23:25:57 -0000 --Apple-Mail=_81FBEBBD-4BC6-40EB-83F6-09AA84BB1F97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The network-instances YANG model [RFC8529] gives an example in Appendix = A.1 of how to use = schema mount to mount the routing protocol. An example modeled along = those lines for the BGP YANG model, and enclosed herewith fails = validation using yanglint with the following error. What am I doing = wrong? Validating yang/example-bgp-configuration-a.1.3.xml err : Unknown element "routing". = (/ietf-network-instance:network-instances/network-instance[name=3D'vrf-red= ']/vrf-root) failed (error code: 0) With confdc it fails as follows: Loading Data for example a.1.3 confd_load: 666: maapi_load_config(sock, tid, flags, abspath(argv[0])) = failed: external error (19): Error on line 9: unknown element: routing = in = /ni:network-instances/ni:network-instance[ni:name=3D'vrf-red']/ni:vrf-root= /rt:routing If what I have is not an error, it raises two questions. Is schema mount = supported? Supported from a validation perspective. I can imagine that = not everyone (or anyone) may have actually implemented schema mount.=20 And the second and more important question is how are routing protocols = supposed to support VRF if the two models, network instance and routing = protocol, do not work together? What needs to change to get them to = work? Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_81FBEBBD-4BC6-40EB-83F6-09AA84BB1F97 Content-Type: multipart/mixed; boundary="Apple-Mail=_4AB771D6-D764-44CB-9824-76FE415E764F" --Apple-Mail=_4AB771D6-D764-44CB-9824-76FE415E764F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = network-instances YANG model [RFC8529] gives an example in Appendix A.1 of how to use schema mount to mount the = routing protocol. An example modeled along those lines for the BGP YANG = model, and enclosed herewith fails validation using yanglint with the = following error. What am I doing wrong?

    Validating = yang/example-bgp-configuration-a.1.3.xml
    err : = Unknown element "routing". = (/ietf-network-instance:network-instances/network-instance[name=3D'vrf-red= ']/vrf-root)
    failed (error code: 0)

    With confdc it fails as = follows:

    Loading Data for example a.1.3
    confd_load:= 666: maapi_load_config(sock, tid, flags, abspath(argv[0])) failed: = external error (19): Error on line 9: unknown element: routing in = /ni:network-instances/ni:network-instance[ni:name=3D'vrf-red']/ni:vrf-root= /rt:routing

    If what I have is not an error, it raises two questions. Is = schema mount supported? Supported from a validation perspective. I can = imagine that not everyone (or anyone) may have actually implemented = schema mount. 

    And the second and more important question is how are routing = protocols supposed to support VRF if the two models, network instance = and routing protocol, do not work together? What needs to change to get = them to work?

    Thanks.

    Mahesh Jethanandani


    = --Apple-Mail=_4AB771D6-D764-44CB-9824-76FE415E764F Content-Disposition: attachment; filename=example-bgp-configuration-a.1.3.xml Content-Type: application/xml; x-unix-mode=0644; name="example-bgp-configuration-a.1.3.xml" Content-Transfer-Encoding: 7bit vrf-red 192.0.2.1 bgpm:bgp BGP 64496 bt:ipv4-unicast vrf-blue 192.0.2.2 bgpm:bgp BGP 64496 bt:ipv4-unicast --Apple-Mail=_4AB771D6-D764-44CB-9824-76FE415E764F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    --Apple-Mail=_4AB771D6-D764-44CB-9824-76FE415E764F-- --Apple-Mail=_81FBEBBD-4BC6-40EB-83F6-09AA84BB1F97-- From nobody Tue Jan 21 23:39:55 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010C120052; Tue, 21 Jan 2020 23:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 plQXnc7jJEWG; Tue, 21 Jan 2020 23:39:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 180D2120013; Tue, 21 Jan 2020 23:39:51 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D49301AE02F0; Wed, 22 Jan 2020 08:39:50 +0100 (CET) Date: Wed, 22 Jan 2020 08:39:13 +0100 (CET) Message-Id: <20200122.083913.1144371370754358519.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: netmod@ietf.org, jhaas@juniper.net, draft-ietf-idr-bgp-model@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Schema mount and Network Instance model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 07:39:54 -0000 Hi, Mahesh Jethanandani wrote: > The network-instances YANG model [RFC8529] gives an example in > Appendix A.1 of how > to use schema mount to mount the routing protocol. An example modeled > along those lines for the BGP YANG model, and enclosed herewith fails > validation using yanglint with the following error. What am I doing > wrong? > > Validating yang/example-bgp-configuration-a.1.3.xml > err : Unknown element > "routing". (/ietf-network-instance:network-instances/network-instance[name='vrf-red']/vrf-root) > failed (error code: 0) > > With confdc it fails as follows: > > Loading Data for example a.1.3 > confd_load: 666: maapi_load_config(sock, tid, flags, abspath(argv[0])) > failed: external error (19): Error on line 9: unknown element: routing > in > /ni:network-instances/ni:network-instance[ni:name='vrf-red']/ni:vrf-root/rt:routing > > If what I have is not an error, it raises two questions. Is schema > mount supported? Supported from a validation perspective. I can > imagine that not everyone (or anyone) may have actually implemented > schema mount. Schema mount is (i) a generic mechanism for composing models at specific mount points and (ii) a way for a server to report to clients how this composition is done in the specific server (this may vary dynamically over time). The network-instance model is generic; it just defines a mount point in the data model. A specific server might be implemented to mount the "ietf-routing" model under the mount point, and in that case it will be able to validate the instance document you provided. However, a generic YANG validator tool does not know (*) which models are supposed to be mounted under any given mount point, and thus it will probably raise an error (as you saw). (*) unless you also pass it additional information about this in some way (this could e.g. in the form of an instance document that contains the /schema-mounts subtree and the ietf-yang-library contents for the mount point) As for implmentation support, we have implemented YANG schema mount in NSO. > And the second and more important question is how are routing > protocols supposed to support VRF if the two models, network instance > and routing protocol, do not work together? What needs to change to > get them to work? I think they do work together! /martin From nobody Wed Jan 22 06:40:54 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5653A1200F6 for ; Wed, 22 Jan 2020 06:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 qoAJPjzn9VnT for ; Wed, 22 Jan 2020 06:40:50 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6A1200F3 for ; Wed, 22 Jan 2020 06:40:50 -0800 (PST) Received: from stubbs.int.chopps.org.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id EF69E60B78; Wed, 22 Jan 2020 14:40:49 +0000 (UTC) User-agent: mu4e 1.3.4; emacs 26.3 From: Christian Hopps To: netmod@ietf.org Date: Wed, 22 Jan 2020 09:40:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [netmod] ID submission YANG validation errors? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 14:40:52 -0000 --=-=-= Content-Type: text/plain; format=flowed I've just submitted a YANG module draft and received what i think to be a bogus validation error: https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ It's saying it can't find the ietf-isis module. Has anyone else experienced this issue with referencing draft modules? It seems broken that we can't refer to works-in-progress, inside our works-in-progress. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl4oXvAACgkQLh2DDte4 MCWe9w/+P1fYKmSJBnO7pwdoPI8OuIoWFN9UKr8Z1bNxGxoOxStC6/DREHqA7HgX k1AtuJbscIowW1GJ1tf+71+g13NqFlHv5lydEgfXtJYE271oJEaT0ealmBCkGUkX C5vtG9627VY/JTXN+7huUNfnff+FoKLY64z4fSDDdq3pbWYRoV5nf+RrDDs5NKuw t7bo/H3A8VgPqwHhJBQkW2xGy64OLIRbkjAuiYfEUMhtjFdSM/PLFyszN9RZ2iYh O3uJFnz0cWOINHZMRoTbct86K7NsTFDRls67U1bzUAkz1x/mRZMX3nshmLbZCi7e kaGuYK8Ia77V2j67PZ3o8kzhLgZ0kb7GomFIJnodMoyLlDNWJPyI9GXzdyQl+Lwz x90f3mm3jj+Lp1cA2k89NopJYDoN3c4r0fGLcBlVHtb1K8oUU/VrlBpYypySBO+T tRrFiDW4uwOz8QUCe7AT+KJXHW84A2RxOgWLF6n1/CmqE1a7+4VvDQr83X1q7by3 mkLu7uKwVmI8Vhd//MR+xpdoDw1JaHVQf3OrdnnaWpGa8U61/07VFBQ3HZT7TaQW xROojJJCV7PL3gAeF4RmYoaXlDcjeUZUJj/tOdnFEiFeM+X5Mb1fPMDEOuB8AWgW tYCGnOMjmYHKA4FcXl9nTyk5TyFTDHyzx1KdbKtUZ/EW5aEL0SE= =ntEI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 22 08:18:05 2020 Return-Path: <0100016fce0bb7fb-28ba05c1-cd23-4ace-997b-f3d7a2f327b4-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A6B120251; Wed, 22 Jan 2020 08:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ZqbZXirX-Wvr; Wed, 22 Jan 2020 08:17:54 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986EC120800; Wed, 22 Jan 2020 08:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1579709872; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=NTdtnEbucoSVCUbTlX5l9EDJzuJYA896BkAW37UUw4I=; b=l2tBCReHThmi9j2cjb3FKXRH0kPPUeyrq25jFQpeW3u5abKp88vhvkj3zO2wQCle 365vaEzTrj06xzLTuPMWuKWnEHTr7P8sDkYJPnucAKAix+Og9mM719XNk6Fdy1jRqXy hHgqm4Bx3Beg/llgfU20ZNUinYD4VLqmlVNvV5Oo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <20200121023012.GC80030@kduck.mit.edu> Date: Wed, 22 Jan 2020 16:17:52 +0000 Cc: The IESG , "netmod-chairs@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-artwork-folding@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <0100016fce0bb7fb-28ba05c1-cd23-4ace-997b-f3d7a2f327b4-000000@email.amazonses.com> References: <157861251031.11821.9719140738474484600.idtracker@ietfa.amsl.com> <597a69b9-a7ec-6b63-65e1-0c64d63574f5@unix-ag.uni-kl.de> <0100016fc5a2305d-ea9d8ddb-cbb4-43dd-a784-312903f199c0-000000@email.amazonses.com> <20200121023012.GC80030@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.22-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 16:17:56 -0000 Hi Ben, > I don't see any further improvements; this looks really nice now. > (I assume Erik was consulted about the Acknowledgments change (and = trust > the RFC Editor to spell "Acknowledgments" according to house style) = that's > also part of the -12.) Yes, Erik and I discussed the Acknowledgments update. We felt that it = was no longer needed now that he is an author on the draft. > I'm updating my position in the datatracker now. Excellent!=20 And, according to Datatracker=E2=80=99s =E2=80=9CIESG evaluation = record=E2=80=9D tab for this draft: Summary: Has enough positions to pass. Kent From nobody Wed Jan 22 08:23:41 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DCF120853; Wed, 22 Jan 2020 08:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Ryn1EYfR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zjGx+b+H 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 ffjxFn1zofel; Wed, 22 Jan 2020 08:23:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6D812084C; Wed, 22 Jan 2020 08:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=920; q=dns/txt; s=iport; t=1579710218; x=1580919818; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VrVEfmy842T6GZO7IsTDL5LV35+LEGa74mLEChnpLe8=; b=Ryn1EYfRgvPw6wLcKqt21SHgIvRbDYZ3LOeICmGLEfAYvElGhZ8Z9cYP LYoDPMfr1jUNLnIDn4A5oCczouguXBRAPy0qOiiHtQpnLD+u6TomulEss VYKNnFmcSe8cZS0BmQArf7taP8bUE4NbMRRDsbQAqfAU9tBWXSGVIpahI E=; IronPort-PHdr: =?us-ascii?q?9a23=3A0KqRdRH0fOc7mYYPX0wzlJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjyJ/PnRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAACydihe/40NJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWgGAQELAYFTUAVsWCAECyqEEoNGA4sFToFsmDOBLoEkA1QJAQE?= =?us-ascii?q?BDAEBJQgCAQGEQAIXggMkNQgOAgMNAQEEAQEBAgEFBG2FNwyFXwIBAxIREQw?= =?us-ascii?q?BATgPAgEIDgwCJgICAjAVEAIEARIigwQBgkoDLgEOpAwCgTmIYXWBMoJ/AQE?= =?us-ascii?q?FgUNBgnoYggwDBoEOKgGMFRqCAIE4DBSCTD6BBAGBXwIDAYFfgxAygiyQVZ8?= =?us-ascii?q?BCoI5hz+OdBuCN5hAjl6IYpImAgQCBAUCDgEBBYFUAjWBWHAVZQGCQVAYDYg?= =?us-ascii?q?BGINbhRSFP3SBKYoCLYIUAQE?= X-IronPort-AV: E=Sophos;i="5.70,350,1574121600"; d="scan'208";a="710073946" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 16:23:36 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MGNa0e020048 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2020 16:23:36 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 10:23:36 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 11:23:34 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 11:23:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bam+ztuysA7oujNvtA1wsTBoDLemaFHyp7tm1Mzi1LrpTA6hQ3KiOKh0OkDYWE6Zj9aCvxC0F5un5FPm0gXWVkfhegIU7taG502NjQTcokUq3WZaQYlqbWk8Rhzq91CCEHnGDItoNttDr2bwzfwy2ZTc/gx7U1mCMK18jn8WTzgiCDPX/YmFhgmzt1Dof/yJJVrBl98jnzVp8J/wQiobYBBOJ4Z4iMbLbUjtuMSemjLJ0OmEcNM5sXOACbob9tZ59zB0MzHU8NM7jFxCScdXWa8ZnITK3Lx7sP3iDAeDwJJd7z0DNfiOeAUJbuUtOlDi2eadRyupfLWxM7iUs+EV1A== 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=VrVEfmy842T6GZO7IsTDL5LV35+LEGa74mLEChnpLe8=; b=I1fm7KH/GKSk43DR+GtZ6ujBDqkfpeA69zw7eUW2FmzhSiMchXDRA7+wqkip6B5H2uay4/xfbRf/szxkp8RKE7li2cvrCi7pInqzmOFcu9uqD6qAGol2YAJGjz7WRKr/Uh8MiIH1qaFHcPm2HAM/sIrGj4pDrrtgWKYRME4GvdDcLZcJwy++JMxgwD6KQSqHw7ZNJQgNf8IaKuLmGkHEIhEecoCl1eZLDlfBUzKTaFMMA4mSUPNmyyK+sdi/9wL7w+gBrb0/4kFlpjm5cvkpbItaXQfq0OMkqPngif9v6Qix/Uw3/ePYURZyQz4v3Kie9A1dUW8iJDUfXUtqzOexGg== 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=VrVEfmy842T6GZO7IsTDL5LV35+LEGa74mLEChnpLe8=; b=zjGx+b+HeYRwqGAl0KTamOElyqR4JLKiKpY1VyM3ybxo5oVSsc+Mm+OJ1SKpYTICRoNQ5jxQrqivBhUpZ8Y2ApTj4EXOWQvkvkTZRRkBBTWjik7+Bdel3OtUB4Vzj4QeXS0QTaMqBEHPiG667cggZvWQ8/ztv4tx6Qh5mUF8HgA= Received: from CY4PR11MB1238.namprd11.prod.outlook.com (10.173.17.17) by CY4PR11MB1463.namprd11.prod.outlook.com (10.172.65.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 22 Jan 2020 16:23:34 +0000 Received: from CY4PR11MB1238.namprd11.prod.outlook.com ([fe80::1410:485c:8874:fe43]) by CY4PR11MB1238.namprd11.prod.outlook.com ([fe80::1410:485c:8874:fe43%8]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 16:23:33 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , "netmod@ietf.org" , YANG Doctors Thread-Topic: [netmod] ID submission YANG validation errors? Thread-Index: AQHV0TH7TQme43ZjH02SVuCKcjvkVKf2il0A Date: Wed, 22 Jan 2020 16:23:33 +0000 Message-ID: References: In-Reply-To: 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:1001::143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce4a3bc1-3664-4ea4-a3f6-08d79f576d39 x-ms-traffictypediagnostic: CY4PR11MB1463: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(199004)(189003)(86362001)(4744005)(2906002)(5660300002)(110136005)(6512007)(6486002)(6506007)(478600001)(36756003)(8936002)(2616005)(8676002)(81156014)(81166006)(316002)(66946007)(64756008)(71200400001)(66446008)(91956017)(966005)(66556008)(66476007)(76116006)(186003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1463; H:CY4PR11MB1238.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mbXZsm6LyEXiSHMw1YxTaaYNK91STO7J2ECubA6cEHDcGjnmA+GfKpFrboNde+5TrC4iJs3c5SNfsCQt3lRt4NjI+QNzR1ftQsBXhihG1Q6NsTJuZsGI1yFsQlT/ZMHuUYBparr9W+MWDoHzN+9rt+oQm1pXhjZ4lar2TzyeDX86D83TBtVSSrZUqhvhoA/znMyc4dvNiFzCW6Arxv2r1SPnw04fvjfzQKpjTOXke7QifgfA/tvsxBT5Sjru7ygY+5qYKS1NuZ8uBLGxUz//bIn4vp2PBmjJBloIXpl10B/bI8OJShAR3v2S4XmV3wFhPF5okXBa90igvkHKZXALqGF0zrVJr4pyQlKTgCcAgz7Ni/c86uu26/L1Q+CIoKtgOZ3qBsIYdvYPuqMeZseJLtGQ49f7d7VWeVnwi54Q2phjsDjNCGcyHHSLh5F91oDGzBoqsaZ7kyO/0ydsqnFIkIlSAKXbr3HOcqZeeOJcCWA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4507D05CEFDE214DBD19E0477DC837D8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ce4a3bc1-3664-4ea4-a3f6-08d79f576d39 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 16:23:33.8640 (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: UBpVDHW7rQ48Tg12OvGO3faqOVYmfMHUrmcarm80x9ecAJA3EJYjaRisa6PpeYaV X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1463 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netmod] ID submission YANG validation errors? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 16:23:40 -0000 QWxzbywgdGhlIFlBTkcgdmFsaWRhdG9yIHRvb2wgaXMgYnJva2VuIC0gaHR0cHM6Ly93d3cueWFu Z2NhdGFsb2cub3JnL3lhbmd2YWxpZGF0b3IvDQoNCu+7v09uIDEvMjIvMjAsIDk6NDEgQU0sICJu ZXRtb2Qgb24gYmVoYWxmIG9mIENocmlzdGlhbiBIb3BwcyIgPG5ldG1vZC1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBjaG9wcHNAY2hvcHBzLm9yZz4gd3JvdGU6DQoNCiAgICANCiAgICBJ J3ZlIGp1c3Qgc3VibWl0dGVkIGEgWUFORyBtb2R1bGUgZHJhZnQgYW5kIHJlY2VpdmVkIHdoYXQg aSB0aGluayB0byBiZSBhIGJvZ3VzIHZhbGlkYXRpb24gZXJyb3I6DQogICAgDQogICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxzci15YW5nLWlzaXMtcmV2 ZXJzZS1tZXRyaWMvDQogICAgDQogICAgSXQncyBzYXlpbmcgaXQgY2FuJ3QgZmluZCB0aGUgaWV0 Zi1pc2lzIG1vZHVsZS4gSGFzIGFueW9uZSBlbHNlIGV4cGVyaWVuY2VkIHRoaXMgaXNzdWUgd2l0 aCByZWZlcmVuY2luZyBkcmFmdCBtb2R1bGVzPyBJdCBzZWVtcyBicm9rZW4gdGhhdCB3ZSBjYW4n dCByZWZlciB0byB3b3Jrcy1pbi1wcm9ncmVzcywgaW5zaWRlIG91ciB3b3Jrcy1pbi1wcm9ncmVz cy4NCiAgICANCiAgICBUaGFua3MsDQogICAgQ2hyaXMuDQogICAgDQoNCg== From nobody Wed Jan 22 14:29:22 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2DA120091 for ; Wed, 22 Jan 2020 14:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AxVhYEv7QdDO for ; Wed, 22 Jan 2020 14:29:18 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1CF120089 for ; Wed, 22 Jan 2020 14:29:18 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id x8so268583pgk.8 for ; Wed, 22 Jan 2020 14:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HciJLXEubsIGU7IzAUviAlz4KBex5IRFR7tSPKvNJgE=; b=k5K+j2x6gB5V8NrOxg6OIZtBYAA+oMvNsJkJsRiMGfUHL46guO1bpfKhDG5LaQXvKm p8p4YaEIJ6RsVlH0osVyryd4nAKppz0lrDYGcPpn52BT+cQ8o05ogDN4K6dOYlC1K8Vo TALGJliJZZjy0Mr/HaAvXwOBAJBeNszxfVslReRJAngpZZe4xwpyMpu4DWqgKk++RpK2 S73wAEJR42T+ci2b5z7RdSsB8I8vf8jMfRS8EuylKTiX8yxVLrb3qWcFEjzDKV03KWLl pliMYBTrMQ2KbNOsiW9r0WzbzH9mrC2CWmjNiwNSRNHTx68RTXXwNAkX+qp0UjTb+/4O mNzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HciJLXEubsIGU7IzAUviAlz4KBex5IRFR7tSPKvNJgE=; b=oPuCnF3SdrN02VdJ87noUPGJbegBaah7cVIqtXIauFQyYJDV4H9IXWOQKml2IQlEK1 2+0UCYyzRMUolj/fWhcWprPgDJYI5Ph+z5A/tH6Zj3Is7jsNCTk3xyrarD2RQWS1pKJi pNsyR/F+BUrbWlJLu9Adm17z006DwQn5WLa4VOJPVoprAJGzc0V/b5ja3y7oH79qmYX7 iLJRQ+j7jKmp/xPj04rwywR9vxaxV6OBN+YoYBcnq2+WWFKjmFIP/1QhFGDFyTxiO8DC ZU3ZhyRA4fUDX/aZzgA8unecx4ha4F0XirAlacrgMLwGwPDU1cbLqc9q0x7QObL+vcxq qfAA== X-Gm-Message-State: APjAAAWoGnzMmARX1sNRC4n+wkwpLgQ3FAbud+GQe7rIGJF2bc8E8yS5 QmYWPsbbHzNppXH1+I616V0Mkdnd X-Google-Smtp-Source: APXvYqzI/KfF4hxREhQB0OcSMRy6V8u3g/NSF9Yhns0nCgVjRyUb/SEDb+bsSUFmfkjHTXoSkuLpHA== X-Received: by 2002:a63:6c82:: with SMTP id h124mr523642pgc.328.1579732158285; Wed, 22 Jan 2020 14:29:18 -0800 (PST) Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id s131sm52135031pfs.135.2020.01.22.14.29.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 14:29:17 -0800 (PST) From: Mahesh Jethanandani Message-Id: <1BBE300F-B664-48D0-8805-792375821051@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3149E621-72EB-4926-997D-5F8C660827F2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 22 Jan 2020 14:29:16 -0800 In-Reply-To: Cc: netmod@ietf.org To: Christian Hopps References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netmod] ID submission YANG validation errors? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 22:29:20 -0000 --Apple-Mail=_3149E621-72EB-4926-997D-5F8C660827F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 22, 2020, at 6:40 AM, Christian Hopps = wrote: >=20 >=20 > I've just submitted a YANG module draft and received what i think to = be a bogus validation error: >=20 > = https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ >=20 > It's saying it can't find the ietf-isis module. Has anyone else = experienced this issue with referencing draft modules? It seems broken = that we can't refer to works-in-progress, inside our works-in-progress. Yes, I experience this error all the time. In this case I am referencing = published IEEE models in YangModels GitHub location. If my local = validation passes, I just ignore these errors: yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p = {tmplib} {model} -i: err : Data model "ieee802-dot1q-types" not found. err : Importing "ieee802-dot1q-types" module into "ietf-if-l3-vlan" = failed. err : Module "ietf-if-l3-vlan" parsing failed. err : Importing "ietf-if-l3-vlan" module into "ietf-routing-policy" = failed. err : Module "ietf-routing-policy" parsing failed. err : Importing "ietf-routing-policy" module into "ietf-bgp" failed. err : Module "ietf-bgp" parsing failed. >=20 > Thanks, > Chris. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3149E621-72EB-4926-997D-5F8C660827F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

    On Jan 22, 2020, at 6:40 AM, Christian Hopps <chopps@chopps.org> = wrote:


    I've just submitted a YANG module draft and = received what i think to be a bogus validation error:

    https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-rever= se-metric/

    It's saying it can't find = the ietf-isis module. Has anyone else experienced this issue with = referencing draft modules? It seems broken that we can't refer to = works-in-progress, inside our works-in-progress.

    Yes, I = experience this error all the time. In this case I am referencing = published IEEE models in YangModels GitHub location. If my local = validation passes, I just ignore these errors:

    yanglint =
    0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} =
    {model} -i:
    err : Data model "ieee802-dot1q-types" not found.
    err : Importing "ieee802-dot1q-types" module into "ietf-if-l3-vlan" =
    failed.
    err : Module "ietf-if-l3-vlan" parsing failed.
    err : Importing "ietf-if-l3-vlan" module into "ietf-routing-policy" =
    failed.
    err : Module "ietf-routing-policy" parsing failed.
    err : Importing "ietf-routing-policy" module into "ietf-bgp" failed.
    err : Module "ietf-bgp" parsing failed.
    


    Thanks,
    Chris.
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod

    Mahesh Jethanandani



    = --Apple-Mail=_3149E621-72EB-4926-997D-5F8C660827F2-- From nobody Wed Jan 22 14:50:50 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ECB120089 for ; Wed, 22 Jan 2020 14:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 PKpzjzYwuNd4 for ; Wed, 22 Jan 2020 14:50:48 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 25F5312001A for ; Wed, 22 Jan 2020 14:50:48 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 961FE60B8D; Wed, 22 Jan 2020 22:50:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Christian Hopps In-Reply-To: <1BBE300F-B664-48D0-8805-792375821051@gmail.com> Date: Wed, 22 Jan 2020 17:50:46 -0500 Cc: Christian Hopps , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <46BA215E-A0FB-436A-A5F3-E63EF2E12E25@chopps.org> References: <1BBE300F-B664-48D0-8805-792375821051@gmail.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [netmod] ID submission YANG validation errors? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 22:50:50 -0000 I've sent some mail previously to random lists (codesprint, xml2rfc..) = and Henrik, but I've not heard back. Does anyone know what the official = path to reporting problems with the yang validation setup is? Thanks, Chris. > On Jan 22, 2020, at 5:29 PM, Mahesh Jethanandani = wrote: >=20 >=20 >=20 >> On Jan 22, 2020, at 6:40 AM, Christian Hopps = wrote: >>=20 >>=20 >> I've just submitted a YANG module draft and received what i think to = be a bogus validation error: >>=20 >> = https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ >>=20 >> It's saying it can't find the ietf-isis module. Has anyone else = experienced this issue with referencing draft modules? It seems broken = that we can't refer to works-in-progress, inside our works-in-progress. >=20 > Yes, I experience this error all the time. In this case I am = referencing published IEEE models in YangModels GitHub location. If my = local validation passes, I just ignore these errors: >=20 > yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p = {tmplib} {model} -i: > err : Data model "ieee802-dot1q-types" not found. > err : Importing "ieee802-dot1q-types" module into "ietf-if-l3-vlan" = failed. > err : Module "ietf-if-l3-vlan" parsing failed. > err : Importing "ietf-if-l3-vlan" module into "ietf-routing-policy" = failed. > err : Module "ietf-routing-policy" parsing failed. > err : Importing "ietf-routing-policy" module into "ietf-bgp" failed. > err : Module "ietf-bgp" parsing failed. >=20 >=20 >>=20 >> Thanks, >> Chris. >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 From nobody Thu Jan 23 08:42:16 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64225120903 for ; Thu, 23 Jan 2020 08:42:14 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 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 4aAwZ63wbu-S for ; Thu, 23 Jan 2020 08:42:12 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C431208FF for ; Thu, 23 Jan 2020 08:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1579797732; x=1581007332; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=trenJJP/M0075uyClC+WejXL61rEpWw+JZ2++whbN/4=; b=FtddQBN9rVQOO4oa0W58+oWBfKd4DAj/6cCN1XVb1b5kVXlZ6Rqc2YTi a/RdyAQ0lqPWYAzqk2UnslQh4ZCCMK7bStMMZoDWa9Nq5nYiYLoFK0aeM IMnhMW2azcK2K40j0U1f7Nz9u+DLeDO4UyXB1IFKMIKxJIp7Vcm+5f0pI o=; X-IronPort-AV: E=Sophos;i="5.70,354,1574121600"; d="scan'208";a="22482519" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 16:42:10 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) (authenticated bits=0) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPSA id 00NGg8D1025997 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2020 16:42:10 GMT To: "Acee Lindem (acee)" , Christian Hopps , "netmod@ietf.org" , miroslav.kovac@pantheon.tech References: Cc: Henrik Levkowetz , Robert Sparks From: Benoit Claise Message-ID: <5ef95923-8b53-5165-6d7c-218c9064cde6@cisco.com> Date: Thu, 23 Jan 2020 17:42:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Authenticated-User: bclaise X-Outbound-SMTP-Client: 10.55.221.36, ams-bclaise-nitro3.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] ID submission YANG validation errors? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 16:42:15 -0000 Fixed, thanks to Miroslav, in cc. Yangvalidator is working now, and correctly saying that there are no errors. Datatracker is still not using the yangvalidator API to validate modules and therefore it is saying that there are errors. This task is on our todo list. If you find more issues like the one below, open an issue: https://github.com/YangCatalog (or https://github.com/YangCatalog/bottle-yang-extractor-validator) Regards, Benoit > Also, the YANG validator tool is broken - https://www.yangcatalog.org/yangvalidator/ > > ÔĽŅOn 1/22/20, 9:41 AM, "netmod on behalf of Christian Hopps" wrote: > > > I've just submitted a YANG module draft and received what i think to be a bogus validation error: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ > > It's saying it can't find the ietf-isis module. Has anyone else experienced this issue with referencing draft modules? It seems broken that we can't refer to works-in-progress, inside our works-in-progress. > > Thanks, > Chris. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 24 10:40:05 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DBF12001E; Fri, 24 Jan 2020 10:40:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-netmod-module-tags@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157989120298.22155.3366054047167792497.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2020 10:40:02 -0800 Archived-At: Subject: [netmod] Alissa Cooper's No Objection on draft-ietf-netmod-module-tags-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 18:40:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-netmod-module-tags-09: 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://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-netmod-module-tags/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments. From nobody Tue Jan 28 03:29:12 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE266120013; Mon, 27 Jan 2020 08:24:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, draft-ietf-netmod-yang-data-ext@ietf.org, joelja@gmail.com, alissa@cooperw.in, Joel Jaeggli , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158014226576.26523.3212940106633384654.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2020 08:24:25 -0800 Archived-At: Subject: [netmod] Protocol Action: 'YANG Data Structure Extensions' to Proposed Standard (draft-ietf-netmod-yang-data-ext-05.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 16:24:26 -0000 The IESG has approved the following document: - 'YANG Data Structure Extensions' (draft-ietf-netmod-yang-data-ext-05.txt) as Proposed Standard This document is the product of the Network Modeling Working Group. The IESG contact persons are Warren Kumari, Ignas Bagdonas and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/ Technical Summary This document defines a mechanism for including abstract data into YANG module that does not directly relate to configuration or operation state. It is implemented as a new extension statement. Working Group Summary WG process was smooth and without controversies. The problem space is well understood by the WG and the consensus on the proposed extension mechanism was reached. Document Quality There is information about several implementations that will support this extension. Document was developed and reviewed by YANG Doctors community. Personnel Joel Jaeggli is the Document Shepherd. Ignas Bagdonas is the Responsible Area Director. IANA Note This document registers a new entry in the existing YANG modules names registry. No other actions by IANA are requested. From nobody Tue Jan 28 11:57:22 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F29B12008C; Tue, 28 Jan 2020 11:57:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, The IESG , draft-ietf-netmod-artwork-folding@ietf.org, netmod@ietf.org, alissa@cooperw.in, Lou Berger , lberger@labn.net, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158024143212.4716.1763708848133365898.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 11:57:12 -0800 Archived-At: Subject: [netmod] Document Action: 'Handling Long Lines in Inclusions in Internet-Drafts and RFCs' to Informational RFC (draft-ietf-netmod-artwork-folding-12.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:57:12 -0000 The IESG has approved the following document: - 'Handling Long Lines in Inclusions in Internet-Drafts and RFCs' (draft-ietf-netmod-artwork-folding-12.txt) as Informational RFC This document is the product of the Network Modeling Working Group. The IESG contact persons are Warren Kumari, Ignas Bagdonas and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ Technical Summary This document defines mechanisms for handling long lines of text in environments of bounded line lengths. The primary target application is handling of long lines of text contained in YANG models, although there is no restriction of applying the specified mechanisms to other types of text documents. Working Group Summary Document went through WG process without notable exceptions. There was significant interest and attention in the WG attributed to this document. No controversial aspects were brought in. Document Quality Input was received from WG participants and YANG Doctors, as well as from RFC Editor. Personnel Document Shepherd is Lou Berger. Responsible Area Director is Ignas Bagdonas. From nobody Thu Jan 30 06:09:02 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CF31200E5; Thu, 30 Jan 2020 06:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KAHSCcYU8D6e; Thu, 30 Jan 2020 06:08:59 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F51F12007C; Thu, 30 Jan 2020 06:08:59 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id c9so4188514wrw.8; Thu, 30 Jan 2020 06:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=QtwsaC9t9ghDHK4r61CWJ06HMvdxC/huecK+7q+1XCs=; b=AWs+ZONY/l1Gig0/BaZmYqLokVG2lwUKmMSoViq2GFFXBSY4BEpfK+a8sGTd/B/cqa FOX3ipDj118YW3wYzoQ4hufPhbpPOJPn+WOIyH3qcWklMFYqxWRYCmyVITFH1oTKx9fQ ybRYwGmyp0RpwQzzzZw7/yGCI57AsHsC5DZ4C11TlVLLK04af9jHajxroKFjM3eK6yjK 5jLDQd55P/bpZS8JPVY01f8EztExhYhIbuHG1FkxhN/2G7TYTAFj0XdBvD7u//jUUvqZ auLq8W+OBP8HkD4iCNi6Bnatl4naysa/BgXgvEJ4Ia2kV40cCNd/6a+O7Gt9XEGXojFr cc7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=QtwsaC9t9ghDHK4r61CWJ06HMvdxC/huecK+7q+1XCs=; b=kWEf2gNIntBkENX9uSreK94F2p2wTPHKvZK1a4/UrRBXbjp05rLRSX6GljV8l4opys /sPGYH9QFKpemTfVkaxpG7qlGI0Oxvdn2IVYUY4k8bkCfkUw2xV4VBv6YsV7i6//46Na 5qLIYhJ7B5xzPytcH70JhQ7vJBymi84e6/EmrSfE69Ixfh8DfmiXJB2VJK9aL0GzPdW+ RwLpE50UJwiyBdYt1wfdHaPtg0fOrIOIltnBoyzOCRWutD4uqBPBVudOhinlZJ3Kjblt aRjBPQQhlZehY5buXH4mKZqNv301p+fu8dsAVUhw6ietzymqGl4adaXc8LvkzwRyskwz t40w== X-Gm-Message-State: APjAAAUra6eBMi9rqTClChVMWH+y8oF6P+ZHgQ8t+YTrq4LZ4EUG12PP 97W+s8pRZ4Gkqsv1MuVU1VuCjnFa8y0+fSXJneT8A3vUjZg= X-Google-Smtp-Source: APXvYqwDdEcYQqQl2sRAMgd6PODMYEWrdHRUXoiUg61wCW33zeYNORA5Hz3wLUPQ2XWH8rp/WnN9RcuGzLpuQXs0PAQ= X-Received: by 2002:adf:ee01:: with SMTP id y1mr6173150wrn.152.1580393337066; Thu, 30 Jan 2020 06:08:57 -0800 (PST) MIME-Version: 1.0 From: Tal Mizrahi Date: Thu, 30 Jan 2020 16:08:44 +0200 Message-ID: To: rtg-ads@ietf.org, draft-ietf-netmod-yang-data-ext@ietf.org Cc: netmod@ietf.org, rtg-dir@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="0000000000007618a6059d5bff20" Archived-At: Subject: [netmod] RtgDir review: draft-ietf-netmod-yang-data-ext X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 14:09:01 -0000 --0000000000007618a6059d5bff20 Content-Type: text/plain; charset="UTF-8" Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-netmod-yang-data-ext-05 Reviewer: Tal Mizrahi Review Date: January 30th, 2020 Intended Status: Standards Track Summary: This document is basically ready for publication, but has two minor issues that should be considered prior to publication. Comments: The document is well-written and clear, even to the non-expert reader. The examples are highly appreciated. Minor issues: - The following definition in the "Terminology" section is recursive, and not very clear at this point in the document (it becomes clearer only after the "Definitions" section). It would be highly recommended to rephrase this: 'YANG data structure: A data structure defined with the "structure" statement.' - The "Definitions" section seems to define a single term, the YANG data structure. It would be best to rename the section. Cheers, Tal Mizrahi. --0000000000007618a6059d5bff20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello,

    I have been selecte= d as the Routing Directorate reviewer for this draft. The Routing Directora= te seeks to review all routing or routing-related drafts as they pass throu= gh IETF last call and IESG review, and sometimes on special request. The pu= rpose of the review is to provide assistance to the Routing ADs. For more i= nformation about the Routing Directorate, please see http://trac.tools.ietf.org/area/= rtg/trac/wiki/RtgDir

    Although these comments are primarily for t= he use of the Routing ADs, it would be helpful if you could consider them a= long with any other IETF Last Call comments that you receive, and strive to= resolve them through discussion or by updating the draft.

    Document:= draft-ietf-netmod-yang-data-ext-05
    Reviewer: Tal Mizrahi
    Review Date= : January 30th, 2020
    Intended Status: Standards Track

    Summary:This document is basically ready for publication, but has two minor issues= that should be considered prior to publication.

    Comments:
    The do= cument is well-written and clear, even to the non-expert reader. The exampl= es are highly appreciated.

    Minor issues:
    - The following definiti= on in the "Terminology" section is recursive, and not very clear = at this point in the document (it becomes clearer only after the "Defi= nitions" section). It would be highly recommended to rephrase this:
    'YANG data structure: A data structure defined with the "stru= cture" statement.'

    - The "Definitions" section se= ems to define a single term, the YANG data structure. It would be best to r= ename the section.

    Cheers,
    Tal Mizrahi.

    --0000000000007618a6059d5bff20-- From nobody Fri Jan 31 08:21:50 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDC9120120 for ; Fri, 31 Jan 2020 08:21:48 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nokia.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 IFTdd1BJMCpO for ; Fri, 31 Jan 2020 08:21:46 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150121.outbound.protection.outlook.com [40.107.15.121]) (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 466DB120103 for ; Fri, 31 Jan 2020 08:21:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EsiYxcMxKQ/V5yYK3BvK6EwqLKUEuBUJrDtWgVYJPRM09Ozh2MDOG/es+57b3iMgb/Bt25wkHvWPlYNNR/xRM46tuAPaMXSuBETAyzugMKjOq13lp3c1m1Er7/oX7ZJXPDzl2jLlVQiKqYJ/aJCrbyDasVjLqEntVowa9B1rWIBZ9m5WsWqcCn7ZQNy6iSl7ujyristi4nihDAkRTM9iB+L8a6JsXY66C8JsOuiCCmS8ztryRVFF//RP+XknqOvV/ki7O5ggf8OKb7OzRTFIaggEUHHIMB/+8+oP5eqqKr7WOUPa1jl4PxAUveijhZ3gtCrMlZ1tXIozBtoNUpcJ+g== 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=dGYKTYXmuTdvEvJobVhiv0n8kmxBYPXr39Lhu+bH8jQ=; b=THF8yW+BglCC7w3iwsNOsPzQChb+PXmP0CUvVWn71gw65BWijlUM1WcHGIPN299eFm5w9Bq4ps3pcvH+B5wb2TXDsj5yOfuiA3pf3Ja1JNgPSRvmfbrLdDCzO2903mpdXyMr6Bnh8K3JAYk1e0wnOe/U2T74VnNaaSxFp61jKmRurR8KV9ECNS+iZHTaM8NSKrc3TtHaBPgZRJfXjjqY7FmUN1PweRJubyA7MJw5FpZW+iJJQMKmphFdV5G53SzJf86d76FB31+DKT3ooSQdcEKW57BzoAXhVzS/iLzyDNO7Moeht7HLLYuswnYctgS2pZs07xziM/g5+JIuy0YC+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dGYKTYXmuTdvEvJobVhiv0n8kmxBYPXr39Lhu+bH8jQ=; b=JhDxdKHnUXLsycTjUPfD8zWvejUGaUXXFnEn6TYLXxagpSGYPtLzUaBZPKxBkbYVrDDbNG/T3n9C2iY0J3UKqYdGDC+rXnNSLAYI40Szp4EwOKQg95CjPEGDptwX3xG/598i0kviDHC/ZXTXkGgOyZ2ozbpe1o0jPr2SJzB8gDc= Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.29.24) by VI1PR07MB6381.eurprd07.prod.outlook.com (10.186.163.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.14; Fri, 31 Jan 2020 16:21:44 +0000 Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::fcbf:bc9d:6366:e93e]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::fcbf:bc9d:6366:e93e%5]) with mapi id 15.20.2707.011; Fri, 31 Jan 2020 16:21:44 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] validating instance data against YANG schema including 'must' statements Thread-Index: AdWxCsORBSgRrCTES6eC/F2G+DspvgAgGU0ACbGh+UA= Date: Fri, 31 Jan 2020 16:21:44 +0000 Message-ID: References: In-Reply-To: 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=jason.sterne@nokia.com; x-originating-ip: [135.245.20.4] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 636ffdba-8f20-4bf0-be40-08d7a669a979 x-ms-traffictypediagnostic: VI1PR07MB6381: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(199004)(189003)(86362001)(66446008)(64756008)(76116006)(71200400001)(8676002)(66946007)(66476007)(966005)(33656002)(8936002)(478600001)(316002)(81166006)(5660300002)(66556008)(81156014)(19273905006)(186003)(52536014)(26005)(6506007)(53546011)(2906002)(55016002)(7696005)(9686003)(4001150100001)(110136005)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6381; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dkn4WUC8jDytMw9pH7n9U2llfKDlU3EjtlqLRd0e58AvWL1nFnZCYM24jg2kYAtkiTCkEW2VJUAFIzIIKSsX4Rzn4thEMdQEJGNexihJ5zztEkv2QZgOwgCfW8/YtMMsjE4F+vl7zUsxoA5VmWeX89xZneLZYhLeqoqStta0ifxEVmDIC9gW3opLuWzdhcYCk4aFOpU8Kt+7lZ06NRNpxrFtLM3EjkFEptLVGme69DEJIqOuJgzy3TacfiwacxI1LqWdBpnakz5YfdP5s6EsXbVtLQlVM4K1wMxpAKBPVg/Jf9YCY/Kxv+QfaCL0jjLKMeVp79v4UmWZvxQyMyKpjMx3U9BQwF+tBRvd+HbPExGJ+jqSnD2zMFc/ZLPWQyuvz1ExXAt9sNq48VhG/zaWg+t52/KzrBuPL84JTDJwv7okufmg3Lz4IgqiKfEIR7GWBnZiOVw7q/EQZ7T0J2UdCs8tAvbVwkI1uDUczLpLNJuC7qGP8aOw6Q5vBT+XZgMlirZGKtjztN5LYEtQA4f+AOvvBOc0FqwPZSIrWbqbp2xgwe+w8L84AL/JSLz32+jYiyn0dgpZMA/0VEaStt8Zmsr2PXC1rYCrVTZu/isTYL3VBCQ6619K6/FeqKRFq1ieVWgDRKkaeT6rZBggrcMghuqDTFVWOAtT3KcxlH9jmfM= x-ms-exchange-antispam-messagedata: VMPm+4xS6a0wIegVOJN6NSXojYsCoq5W1UkSGAVMSXbglRgU8QSMcDVvr+zB8NRP8JVG+EcwGzEd1/iUyNDbbbenrUF1agaIBUD7XZeJ2PK+TT0JG/LjC3ewRKd8om0uric9/HGjqFvbMs7hUapK+w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 636ffdba-8f20-4bf0-be40-08d7a669a979 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 16:21:44.0390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9VgXvWq1x23Gyex9+XYZ7DPrQG3drFntPM/sNQRnatRJrphtUJd7vMPlYrr1pe3KuZx7zSyCaXLNSaCMhvikCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6381 Archived-At: Subject: Re: [netmod] validating instance data against YANG schema including 'must' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 16:21:49 -0000 Thx Lada. If I only have XML (e.g. from a NETCONF interface) I suppose I could use ya= nglint, e.g. this type of usage: yanglint --format=3Djson --type=3Dconfig --output=3Ddata.json ./a= ll-my-modules/*.yang ./data.xml Is that correct? I believe yanglint can also validate instance data against a YANG schema. C= an anyone confirm that yang2dsdl and yanglint do *not* validate against the= 'must' statements? Jason > -----Original Message----- > From: netmod On Behalf Of Ladislav Lhotka > Sent: Friday, December 13, 2019 2:59 AM > To: netmod@ietf.org > Subject: Re: [netmod] validating instance data against YANG schema includ= ing > 'must' statements >=20 > On Thu, 2019-12-12 at 16:42 +0000, Sterne, Jason (Nokia - CA/Ottawa) wrot= e: > > Hi all, > > > > A few years ago there were a few discussions on the list about tools to > > validate instance data (e.g. the data returned by a ) again= st a > > YANG model. > > > > yang2dsdl is one option but I'm pretty sure it doesn't actually check t= he data > > against 'must' statements. > > > > Are there some tools that check against 'must' (and 'when') statements? > Do > > those tools also work with YANG 1.1 modules? >=20 > Yangson does a complete validation, and supports YANG 1.1, but only JSON > representation of instance data. The GitHub link is below, a PyPI package= is > also available: >=20 > https://pypi.org/project/yangson/ >=20 > Lada >=20 > > > > Thx, > > Jason > > > > > ############################################################### > ############### > > ######################## > > Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 =3D> 16.10-5..1 > > Ladislav Lhotka Tue, 07 March 2017 12:42 UTCShow > header > > > > Kent Watsen ; writes: > > > > > Hi Benoit, > > > > > > You seem to know the ins and outs of many tools these days, maybe you > > > can point me in the right direction...which tool is able to validate > > > instance documents against YANG 1.1 modules? > > > > Yangson can validate JSON documents: > > > > https://github.com/CZ-NIC/yangson > > > > > > > > I've always used `yang2dsdl`, but currently it outputs "DSDL plugin > > > supports only YANG version 1". > > > > I considered updating the DSDL plugin to 1.1 but it turned up to be > > immensely difficult - it would basically require a complete rewrite. An= d > > even then, the Schematron implementation that is included in pyang > > distribution won't support the new XPath functions. > > > > Lada > > > > > ############################################################### > ############### > > ######################## > > > > Re: [netmod] DSDL plugin in pyang > > Ladislav Lhotka Tue, 29 November 2016 13:39 UTCShow > header > > > > Hi William, > > > > apart from yang2dsdl, I have personal experience with these two instanc= e > > validation tools: > > > > * yanglint - written in C, supports both XML and JSON instance encoding > > > > https://github.com/CESNET/libyang > > > > * yangson - written in Python, supports only JSON > > > > https://github.com/CZ-NIC/yangson > > installation: pip install yangson > > manual page: http://yangson.readthedocs.io/en/latest/cmdline.html > > > > Lada > > > > William Lupton ; writes: > > > > > Are you able to provide a list (either privately or via the NETMOD li= st) of > > other instance data validators that are available and cover YANG 1.1 > features? > > Tx, W. > > > > > >> On 25 Nov 2016, at 14:33, Ladislav Lhotka ; wrote: > > >> > > >> Hi, > > >> > > >> for users of $subj: I modified the plugin so that it now immediately > > refuses to process modules of yang-version greater than 1. Supporting s= ome > of > > the YANG 1.1 features (new XPath functions, leafref handling) would req= uire > > massive changes and I cannot do them now - I am not even sure it is wor= th > the > > effort given that other instance data validators are available. > > >> > > >> Lada > > > > -- > > > > > ############################################################### > ############### > > ######################## > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 31 09:45:38 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52483120A96 for ; Fri, 31 Jan 2020 09:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 lUm-QRL646xT for ; Fri, 31 Jan 2020 09:45:29 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B615912021C for ; Fri, 31 Jan 2020 09:45:29 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id p11so3012608plq.10 for ; Fri, 31 Jan 2020 09:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1AfsioIr/OXJizQ/sqH9pFfPkp9UZ/l2S+4oLS9XvJU=; b=gW43xcm6BuE/nMutFzqL9llP/CKAg8fHHp5Mj2UehRrufeJjCHYqVQYwEaL3fp7L+F zrI3c+ktpoUdc3Vm8dFMpmQ++MTnxkn9Gp9DedTqpWVhKMaiMuq40LV/86ymXKfGLqi4 zQC4CIlug8SWIboDrFpY2uuJ2wg0Ncn4hmVymGqQS2Y2ZPKJWuVzLVMDY58tT/lRpYcW U2ehrC3ckmmjMnw47d8UJsJchubHr/QOpyc4hR+TCubmwouhF5VaE8V3uN27vMZus+so ZH4ec8zMAuKlJEA1nVO7xM/KP/wmp+Pe8sRf97A0YlTrxPjev8KE9teSbGdUVvGHrG4M H2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1AfsioIr/OXJizQ/sqH9pFfPkp9UZ/l2S+4oLS9XvJU=; b=Yz8wqxScSg75TYiHScHSUxzkxcdHYIIUTcac2qIOSDLqrpJsU7mjzj0z0NQH1hyUnL SiTlo+s+BZRIOeLU622qOKZ1T8meT6W7GIj7+AxuLtL5U6GvZ063w2a7B/t5qGB1sNQf aIrkClr9a21auC0JtGOyiFLFPlTdhNWn6ckRUCHVNt4jkIXg4WznYkBbSVavrbw3Aqlo 4YWZYMN4I0hpR3sS8W80Ycdm1Xr9SrosNkuN21cLZOPvGuMrWEtfTn9pilBSnGS7yJ/V VPuoNhEo/GxUGk6ZQAD+BOj7oDLZpr9xhtPiwoe6UUzj6tXlnGWvo2mjfbxEKbeFjGdq dlYQ== X-Gm-Message-State: APjAAAWJTASLSQ3qXafguYhemorHtIhc8139j6RhDOmrb8vCz3sw4JiI ul0ZZCDe1eKBtbFTY9D1PcY= X-Google-Smtp-Source: APXvYqxcBFUgQ9wKiemvnH34T+G8xTr+RE8oN4BqyFr+2W5Ir7aVEs0NtH/8Jn/w3W4ooypP180Gcw== X-Received: by 2002:a17:902:59c9:: with SMTP id d9mr11132842plj.184.1580492729115; Fri, 31 Jan 2020 09:45:29 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:558b:dc24:5bc9:2f9? ([2601:647:5600:5020:558b:dc24:5bc9:2f9]) by smtp.gmail.com with ESMTPSA id g18sm11028989pfi.80.2020.01.31.09.45.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jan 2020 09:45:28 -0800 (PST) From: Mahesh Jethanandani Message-Id: <650ADE92-EAC1-4C8E-ACB3-433B95645AFE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E31155D5-6D97-43D7-8397-774A71563361" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 31 Jan 2020 09:45:26 -0800 In-Reply-To: Cc: Ladislav Lhotka , "netmod@ietf.org" To: Jason Sterne References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netmod] validating instance data against YANG schema including 'must' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 17:45:33 -0000 --Apple-Mail=_E31155D5-6D97-43D7-8397-774A71563361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jason, yanglint does validate XML instance data for must statements: MAHESH-M-M8D1:/Volumes/External/git/my-YANG-public/src/model/draft *833 = > yanglint -t auto -s -i -p common = ../../../build/mef-legato-services@2018-07-17.yang = MEF6.2-bwp-per-uni-mef-interface-configuration.xml=20 err : Must condition ". >=3D 1 and . <=3D count(../../bwp-flow/rank)" = not satisfied. = (/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfa= ces/uni[uni-id=3D'ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/enve= lope[id=3D'ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank=3D'3']/rank) err : The rank of a Bandwidth Profile Flow must be between 1 and n, where n is the number of flows in the Envelope = (/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfa= ces/uni[uni-id=3D'ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/enve= lope[id=3D'ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank=3D'3']/rank) > On Jan 31, 2020, at 8:21 AM, Sterne, Jason (Nokia - CA/Ottawa) = wrote: >=20 > Thx Lada. >=20 > If I only have XML (e.g. from a NETCONF interface) I suppose I could = use yanglint, e.g. this type of usage: > yanglint --format=3Djson --type=3Dconfig --output=3Ddata.json = ./all-my-modules/*.yang ./data.xml >=20 > Is that correct? >=20 > I believe yanglint can also validate instance data against a YANG = schema. Can anyone confirm that yang2dsdl and yanglint do *not* validate = against the 'must' statements? >=20 > Jason >=20 >> -----Original Message----- >> From: netmod On Behalf Of Ladislav Lhotka >> Sent: Friday, December 13, 2019 2:59 AM >> To: netmod@ietf.org >> Subject: Re: [netmod] validating instance data against YANG schema = including >> 'must' statements >>=20 >> On Thu, 2019-12-12 at 16:42 +0000, Sterne, Jason (Nokia - CA/Ottawa) = wrote: >>> Hi all, >>>=20 >>> A few years ago there were a few discussions on the list about tools = to >>> validate instance data (e.g. the data returned by a ) = against a >>> YANG model. >>>=20 >>> yang2dsdl is one option but I'm pretty sure it doesn't actually = check the data >>> against 'must' statements. >>>=20 >>> Are there some tools that check against 'must' (and 'when') = statements? >> Do >>> those tools also work with YANG 1.1 modules? >>=20 >> Yangson does a complete validation, and supports YANG 1.1, but only = JSON >> representation of instance data. The GitHub link is below, a PyPI = package is >> also available: >>=20 >> https://pypi.org/project/yangson/ >>=20 >> Lada >>=20 >>>=20 >>> Thx, >>> Jason >>>=20 >>>=20 >> ############################################################### >> ############### >>> ######################## >>> Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 =3D> = 16.10-5..1 >>> Ladislav Lhotka Tue, 07 March 2017 12:42 UTCShow >> header >>>=20 >>> Kent Watsen ; writes: >>>=20 >>>> Hi Benoit, >>>>=20 >>>> You seem to know the ins and outs of many tools these days, maybe = you >>>> can point me in the right direction...which tool is able to = validate >>>> instance documents against YANG 1.1 modules? >>>=20 >>> Yangson can validate JSON documents: >>>=20 >>> https://github.com/CZ-NIC/yangson >>>=20 >>>>=20 >>>> I've always used `yang2dsdl`, but currently it outputs "DSDL plugin >>>> supports only YANG version 1". >>>=20 >>> I considered updating the DSDL plugin to 1.1 but it turned up to be >>> immensely difficult - it would basically require a complete rewrite. = And >>> even then, the Schematron implementation that is included in pyang >>> distribution won't support the new XPath functions. >>>=20 >>> Lada >>>=20 >>>=20 >> ############################################################### >> ############### >>> ######################## >>>=20 >>> Re: [netmod] DSDL plugin in pyang >>> Ladislav Lhotka Tue, 29 November 2016 13:39 UTCShow >> header >>>=20 >>> Hi William, >>>=20 >>> apart from yang2dsdl, I have personal experience with these two = instance >>> validation tools: >>>=20 >>> * yanglint - written in C, supports both XML and JSON instance = encoding >>>=20 >>> https://github.com/CESNET/libyang >>>=20 >>> * yangson - written in Python, supports only JSON >>>=20 >>> https://github.com/CZ-NIC/yangson >>> installation: pip install yangson >>> manual page: http://yangson.readthedocs.io/en/latest/cmdline.html >>>=20 >>> Lada >>>=20 >>> William Lupton ; writes: >>>=20 >>>> Are you able to provide a list (either privately or via the NETMOD = list) of >>> other instance data validators that are available and cover YANG 1.1 >> features? >>> Tx, W. >>>>=20 >>>>> On 25 Nov 2016, at 14:33, Ladislav Lhotka ; wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> for users of $subj: I modified the plugin so that it now = immediately >>> refuses to process modules of yang-version greater than 1. = Supporting some >> of >>> the YANG 1.1 features (new XPath functions, leafref handling) would = require >>> massive changes and I cannot do them now - I am not even sure it is = worth >> the >>> effort given that other instance data validators are available. >>>>>=20 >>>>> Lada >>>=20 >>> -- >>>=20 >>>=20 >> ############################################################### >> ############### >>> ######################## >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_E31155D5-6D97-43D7-8397-774A71563361 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jason,

    yanglint does = validate XML instance data for must statements:

    MAHESH-M-M8D1:/Volumes/External/git/my-YANG-public/src/model/dr= aft *833 > yanglint -t auto -s -i -p common ../../../build/mef-legato-services@2018-07-17.yang = MEF6.2-bwp-per-uni-mef-interface-configuration.xml 
    err : Must condition ". = >=3D 1 and . <=3D count(../../bwp-flow/rank)" not = satisfied. = (/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfa= ces/uni[uni-id=3D'ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/enve= lope[id=3D'ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank=3D'3']/rank)
    err : The rank of a Bandwidth Profile Flow must = be
    between 1 and n, where n is the number of = flows
    in the Envelope = (/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfa= ces/uni[uni-id=3D'ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/enve= lope[id=3D'ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank=3D'3']/rank)

    On Jan 31, 2020, at 8:21 AM, Sterne, Jason (Nokia - = CA/Ottawa) <jason.sterne@nokia.com> wrote:

    Thx = Lada.

    If I only have XML (e.g. from a = NETCONF interface) I suppose I could use yanglint, e.g. this type of = usage:
    yanglint    --format=3Djson =    --type=3Dconfig   --output=3Ddata.json =   ./all-my-modules/*.yang ./data.xml

    Is that correct?

    I believe = yanglint can also validate instance data against a YANG schema. Can = anyone confirm that yang2dsdl and yanglint do *not* validate against the = 'must' statements?

    Jason

    -----Original = Message-----
    From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav = Lhotka
    Sent: Friday, December 13, 2019 2:59 AM
    To: netmod@ietf.org
    Subject: Re: [netmod] = validating instance data against YANG schema including
    'must' statements

    On Thu, = 2019-12-12 at 16:42 +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
    Hi all,

    A few years ago there were a few discussions on the list = about tools to
    validate instance data (e.g. the data = returned by a <get-config>) against a
    YANG model.

    yang2dsdl is one option but I'm pretty sure it = doesn't actually check the data
    against 'must' = statements.

    Are there some tools that check = against 'must' (and 'when') statements?
    Do
    those tools also work = with YANG 1.1 modules?

    Yangson = does a complete validation, and supports YANG 1.1, but only JSON
    representation of instance data. The GitHub link is below, a = PyPI package is
    also available:

    https://pypi.org/project/yangson/

    Lada


    Thx,
    Jason


    ##################################################= #############
    ###############
    ########################
    Re: = [netmod] Toolchain upgraded to yangdump-pro 16.10-5 =3D> = 16.10-5..1
    Ladislav Lhotka <lhotka@nic.cz> Tue, 07 = March 2017 12:42 UTCShow
    header

    Kent = Watsen <kwatsen@juniper.net>; writes:

    Hi Benoit,

    You seem to know the ins and outs of many = tools these days, maybe you
    can point me in the right = direction...which tool is able to validate
    instance = documents against YANG 1.1 modules?

    Yangson can validate JSON documents:

    https://github.com/CZ-NIC/yangson


    I've = always used `yang2dsdl`, but currently it outputs "DSDL plugin
    supports only YANG version 1".

    I considered updating the DSDL plugin to 1.1 but it turned up = to be
    immensely difficult - it would basically require a = complete rewrite. And
    even then, the Schematron = implementation that is included in pyang
    distribution = won't support the new XPath functions.

    Lada


    ##################################################= #############
    ###############
    ########################

    Re: [netmod] DSDL plugin in pyang
    Ladislav = Lhotka <lhotka@nic.cz> Tue, 29 November 2016 13:39 UTCShow
    header

    Hi William,

    apart = from yang2dsdl, I have personal experience with these two instance
    validation tools:

    * yanglint - = written in C, supports both XML and JSON instance encoding

     https://github.com/CESNET/libyang

    * yangson - written in Python, supports only = JSON

    =  https://github.com/CZ-NIC/yangson
    =  installation: pip install yangson
     manual = page: http://yangson.readthedocs.io/en/latest/cmdline.html

    Lada

    William = Lupton <wlupton@broadband-forum.org>; writes:

    Are you able to provide = a list (either privately or via the NETMOD list) of
    other instance data validators that are = available and cover YANG 1.1
    features?
    Tx, W.

    On 25 Nov 2016, at 14:33, Ladislav Lhotka = <lhotka@nic.cz>; wrote:

    Hi,

    for users of $subj: I modified the plugin so = that it now immediately
    refuses = to process modules of yang-version greater than 1. Supporting some
    of
    the YANG 1.1 features (new XPath functions, leafref handling) = would require
    massive changes and I cannot do them now - I = am not even sure it is worth
    the
    effort given that other = instance data validators are available.

    Lada

    --


    ##################################################= #############
    ###############
    ########################

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod
    --
    Ladislav Lhotka
    Head, CZ.NIC Labs
    PGP Key ID: = 0xB8F92B08A9F76C67

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod

    = --Apple-Mail=_E31155D5-6D97-43D7-8397-774A71563361-- From nobody Fri Jan 31 10:50:01 2020 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E72120105; Fri, 31 Jan 2020 10:50:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netmod-chairs@ietf.org, ibagdona@gmail.com, kent+ietf@watsen.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158049660006.21227.5635114045175354788.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2020 10:50:00 -0800 Archived-At: Subject: [netmod] netmod - Update to a Meeting Session Request for IETF 107 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:50:00 -0000 An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: netconf Technology Overlap: rtgwg i2rs teas Key Participant Conflict: saag People who must be present: Lou Berger Joel Jaeggli Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: Please place the first session in the first half of the week (i.e., M-W). --------------------------------------------------------- From nobody Fri Jan 31 16:55:09 2020 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40C512002E; Fri, 31 Jan 2020 16:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 YKCo8Ohys1gK; Fri, 31 Jan 2020 16:55:03 -0800 (PST) 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 B871E120013; Fri, 31 Jan 2020 16:55:03 -0800 (PST) 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 0110swHR008427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 19:55:00 -0500 Date: Fri, 31 Jan 2020 16:54:57 -0800 From: Benjamin Kaduk To: Christian Hopps Cc: The IESG , netmod-chairs@ietf.org, joelja@gmail.com, draft-ietf-netmod-module-tags@ietf.org, netmod@ietf.org Message-ID: <20200201005457.GB91553@kduck.mit.edu> References: <155499058804.22746.2191211977799773380.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 00:55:06 -0000 Sorry for letting this sit so long; I must have missed it somewhere (and thanks Alissa for the reminder!) On Fri, May 03, 2019 at 01:48:45PM -0400, Christian Hopps wrote: > > > > On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think this document does introduce new security considerations, > > specifically the ability for one user to remove ("mask") tags from being > > visible to other users. A malicious user could interfere with the > > operations of other users/entities, especially in the case mentioned in > > an example where multiple semi-independent clients use tags to indicate > > modules to avoid that may be broken. > > So here was the thinking on this, since this document doesn't define any actions or behaviors based on tags (or the lack of them) it's hard to talk about what the security considerations would be. However, it is expected that to be useful users (or future specifications) *will* define behaviors based on tag use. The security section does talk about this case: > > " > Users of the tag-meta data may define various actions to be taken > based on the tag meta-data. These actions and their definitions are > outside the scope of this document. Users will need to consider the > security implications of any actions they choose to define. > " > > Which I believe covered this. For example, if an RFC were to define a behavior based on the tag presence then it would need to talk about the security concerns with that behavior. In some sense it covers this, but my Discuss is more about the somewhat-subtle point involving somewhat "long-range" interactions that it doesn't seem reasonable to expect people specifying tags to think about without help. > If this doesn't adequately cover your concern though, do you have a bit of suggested text we could add? I'd suggest to add another clause at the end of the paragraph you quoted: ", including the potential for a tag to get 'masked away' by another user." > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > Section 2 > > > > Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better > > than "standard prefix". > > > > Section 2.4 > > > > Similarly, "future registration" or "future use" seem to be better fits > > for the intended sentiment. > > > > Section 3.2 > > > > I may be misreading, but this seems to be encouraging implementations to > > add new ietf:-prefixed tags that are not necessarily registered or > > specified in IETF-consensus documents. > > > > Section 7.2 > > > > This registry allocates prefixes that have the standard prefix > > "ietf:". [...] > > > > The registry name just talks about "tags"; are we really allocating > > *prefix*es? > > > > Fixed these, thanks. Thanks! -Ben