Re: [Last-Call] [EXT] Yangdoctors last call review of draft-ietf-rtgwg-qos-model-03
"Aseem Choudhary (asechoud)" <asechoud@cisco.com> Sun, 11 July 2021 08:15 UTC
Return-Path: <asechoud@cisco.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62E23A2683; Sun, 11 Jul 2021 01:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.694
X-Spam-Level:
X-Spam-Status: No, score=-7.694 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=KstmQ/rZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Noq3844y
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 zdjzrq8DZrNU; Sun, 11 Jul 2021 01:15:26 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0163A2680; Sun, 11 Jul 2021 01:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70123; q=dns/txt; s=iport; t=1625991325; x=1627200925; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xA7vodxmY9qSJw20NYkeuvXU5sJDOWFa4Uu8VE2aLS8=; b=KstmQ/rZFL8uLnWWF/Ryykp/yvIsM06uyuDVDKF9AY0v4MwRi/YSukcH hP96XXcOQGFXeP2PUcSchQwynteuqHeqxM9zzlUUZElXTwmx9nEaSagn7 anbgnOJ9KuBtXex5gum4JKR4+0s7Gaw0FHf3OTMIn625gTxyykV/vvJbM 8=;
X-IPAS-Result: A0CGAwDnp+pgl5tdJa1RCR4BAQsSDIM8MCMGKH5aNzGESINIA4U5iFYDgRCOV4pDgUKBEQNUAwgBAQENAQE1DAQBAYRUAheCYQIlOBMCBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohTsIJQEMhkUBAQEEEggBCAQZAQEpDgEPAgEGAhEBAgEBASEBBgMCAgIwFAMGCAIEDgUigk8BgX5XAy8BAgyMNo80AYE6Aoofen8zgQGCBwEBBgQEhTwYgjIDBoE6gnuCcVNIAQGCZ4N7JxyBSUSBFScMEIIrNz6CYgICAYEgEUMJDQmCYTaCDCKCHwoQWwYCPCYBAxgFJhAEHiQ1BAYMOgIRBgEeAQQFBgwNBQYGAh8KDwORMC6DDYgyN4x8kAN6gRYKgySKMY4mhV0FJoNji12GO5BXlgKCG4oTk0sICwSEcAIEAgQFAg4BAQaBciKBW3AVGiEqAYI+UBkOjC2BcgwNCYECAQcCgkKFFIVJAXM4AgMDAQkBAQMJiSktghgBAQ
IronPort-PHdr: A9a23:0hjJ4B3QcT4+3lxzsmDPs1BlVkEcU/3cPwMJ5Nwgkb0dOqig/pG3O kvZ6L0tiVLSRozU5rpCjPaeqKHvX2EMoPPj+HAPeZBBTVkJ3MMRmQFzAcOZBwv8NvG5JyA/F d5JAVli+XzzOENJGcH4MlvVpHD67TMbFhjlcwRvIeGgEY/JhMPx3Oe3qPXu
IronPort-HdrOrdr: A9a23:AGf93K/NBOauDHPI1thuk+ASI+orL9Y04lQ7vn2ZKSY+TiX4rb HNoB1173PJYVoqN03I+urwW5VoI0m8yXcd2+B4UItKNDOMhILCFuFfBOXZrQEJG0fFh5Vg/J YlSYdSIpnbN38St7ee3OG7eexQuuVuJsqT9JrjJ3QGd3AXV0l5hT0JbjpyiidNNXF77ZxSLu v62iIWzwDQH0j+d66AdwA4Y9Q=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.84,231,1620691200"; d="scan'208,217";a="746946661"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2021 08:15:23 +0000
Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 16B8FNLe021637 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sun, 11 Jul 2021 08:15:23 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 11 Jul 2021 03:15:23 -0500
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 11 Jul 2021 03:15:22 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Sun, 11 Jul 2021 03:15:22 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsN/scIF1wi6CvP9510c7rUOUyp9w7imc46th1x6Xfwhc0VYcbn7BxP5oMqF9NA3S96PGsfYi2iUELF/nxZGYcLTYAzxs56T80lm8amGkKWJaWabhc8kMi7nDy4j/qTWNZ//WxLb2KX3q/JIQlS5eIuc8rzyjVZiBmGKhKS6uD9A/Ty3muZzxdcpDPRybDiPelFXkznf4QPaMCVLS/JkuCCuqPk8DFC/ijPCoc9bA3xurmSIwI9FNny6Qb3PpUDNdvRX53AvrDgYmvG+9jJneY7r6iitnIhefZ/m4y1fc0KPYsqrvL/jAfpGRB8vRegn3X38jQx14rWKLIT3Cl2Jtw==
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=xA7vodxmY9qSJw20NYkeuvXU5sJDOWFa4Uu8VE2aLS8=; b=G+ES9rLE22r8xuSNvUQBXq6E+R6NDE8VQ90IlsyDkuEw/hILNptSyWjxivWasZZoWjXuoG73WN36LEHjL02O49XnJq4Cqyj6XVRvSMSpTrla0hhYQ4+oZ/IihGfUcP2vA0nsQpxAQ5/RrlQ9cqQAbyC/V+QBdlFZDbzkVxclDvlPwsNsK1XD2riIUp5akKore+LppL3u98oWyzbWn/rYx8Ne8ktiENLFgVD9mzwycyjQ8if92W4onXOuLpONQk+LhjpyvBxBe+PEfUWlsGdSbkj2Q4wGg9q9YRiP1AIGfIEMpsXI9jNzpFJSw229aHedrFS463OgkuOGxo7dCKgHlQ==
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=xA7vodxmY9qSJw20NYkeuvXU5sJDOWFa4Uu8VE2aLS8=; b=Noq3844yNdONVDVzfFVNn0tpT49wFuAlGEINboHmtshxT1MLIhkRRJI+bVhEpskPWE2Y0lyUDiLk3VFp/piQjtTNhy6kZFC/ha1XBsNkF/B7VybV2RnUnk2HVp0dWTAHdYOUzsQ0EU4j67+v0aHQ1XsCijIOE9Amo9lJ6zWVYyM=
Received: from BYAPR11MB3174.namprd11.prod.outlook.com (20.177.127.27) by BY5PR11MB4149.namprd11.prod.outlook.com (10.255.163.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Sun, 11 Jul 2021 08:15:19 +0000
Received: from BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::fcaf:897d:acce:3217]) by BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::fcaf:897d:acce:3217%5]) with mapi id 15.20.4308.026; Sun, 11 Jul 2021 08:15:19 +0000
From: "Aseem Choudhary (asechoud)" <asechoud@cisco.com>
To: "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "draft-ietf-rtgwg-qos-model.all@ietf.org" <draft-ietf-rtgwg-qos-model.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: [EXT] Yangdoctors last call review of draft-ietf-rtgwg-qos-model-03
Thread-Index: AQHXME+jKQ+moCiiIkKTZatSwDlcs6rA5cVIgBAJtYCAbJRRgA==
Date: Sun, 11 Jul 2021 08:15:18 +0000
Message-ID: <24902737-EE40-46E8-B62F-A5B7C449198B@cisco.com>
References: <8728_1618309655_60757217_8728_899_1_161830965310.19073.2939550325560942114@ietfa.amsl.com> <MN2PR09MB59775533427D40429F0DC86FA1469@MN2PR09MB5977.namprd09.prod.outlook.com> <DB6EF6E2-2EC2-405F-B2B1-28801757E01D@cisco.com>
In-Reply-To: <DB6EF6E2-2EC2-405F-B2B1-28801757E01D@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eb8576b9-ff87-400b-15d2-08d944440583
x-ms-traffictypediagnostic: BY5PR11MB4149:
x-microsoft-antispam-prvs: <BY5PR11MB4149821C47ADAE043343982BC2169@BY5PR11MB4149.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KQE9qZLiKNW8/6UD1PxSR94t/IsqJ4dt3XRljtJlAFfoaYNq353nhls40jAV4/buroQ4oVfxc4tucucPuFkXIKaAU/LFSjj7nkybWQ0l29x8iNvYKsNRiQ5T2KSNL1VEMfAYz955sPz1j2uctZfWdGs5plwr+edFrLehrDLIVrPG3BGiPvADMZ6y7zTFjVfKLAC0Sn5hp2oO1clHstpKbkG407BeAN/xZNt/0J2UfRpD6oOBQ5FxKO/GTFHuhhmshlJ5OpBNmETIGXQSxD+NHO8zoa/hMDor0uhlkPi+XEGH0Uq1MwtRfPJXMAWQc8shS++PN73PppL+lh/4zqxht38STBykZCpX7VS8Djc8joPRTJRruCgDg7ZZQC/9k+uVKIdWoayhqawDrJJQJeat33WCU9PsCWDSSfC/X/c+TE+K7GoEuTf9zVKMrXhMFiYb3NNzEraNuOAz+bttY5V/9euHX13zDAsyvkPQiGFzhkN+fF4aftTQBRwqDhNTs4FW4ZShQtLdy+5shfLbZXrSLCdBuLmII523tmjPLXqFZU0nUwEsaJisFKasaSDeGNIm9GsGfQVUKXW8B+V6NmHRivDFqBIGQX37e37e7LKH9ZWvBj6VOnAP+iT3TS9Nz1dcRh3no/ig8ney80GySQNnaghZ8B3zJJJx2Hb+LqNzFzsIUxq09XIDPPsij1h39yPk8Y8lWntA6unvxeegFSRko2+3kcJjkC77P0I7wQS4ZUJxvlvVFrkSLSrScV7xveeIcwf2CMSBXpBFo2Q4ifNb/LsUFsfMDDkXVV9bo/rltWs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3174.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(136003)(366004)(396003)(71200400001)(66946007)(6916009)(166002)(8936002)(64756008)(76116006)(966005)(2906002)(38100700002)(54906003)(33656002)(2616005)(30864003)(122000001)(6506007)(316002)(66574015)(53546011)(83380400001)(186003)(9326002)(4326008)(478600001)(36756003)(66446008)(6512007)(5660300002)(450100002)(66476007)(6486002)(86362001)(8676002)(66556008)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Oe9FTd6WjTpIzmj1HpXDum6Hs1QcGlYsLfO7Nm/toXFwEG1BOF4JoB9bwQwemz+AFQ+4hNT4NF9P15MMMNIrhnnNOT2f3GEBpTkZprwinfZllodRDfHtbPpz/BiKKrilcGY6ctpOxeXOnIsWsuY7y8dT9mexBv+b/GH0lZZoHFE7iK3D/FJgcunPmIL3kg8ciCURO/+7Ozqw+zLPqIjbU5AJ9qcCftBP6sRxcHBKMCn/sYYccV58vFSpS7mbMRPDMmPYX5m+e9td7BODRFQXmIfK85V8J4H9l5crIGV2h9yyV3XU0tq5FRFXuHYpmCeu/bZHWfJHYgOYg0ypUre21fiDaNO69TgcOrt87LNc+iJwOhjMpU3qfTotZUaYoRe/LLuL9Lx8FT5Zf2VWVZxoUTN1gAtkNvnqW+SC+meRPzYhcHfHxj1XjH97U0RdV/jlKaCD47hE8OOmDBkAZzAaB7obhFBcfB814Ckp8uokASeZ5tNyi5s1ZZiqEWdodZbyUSAtDBrwNUdGx3vj/Ned+7SaG/rtKCnkRPqGxLH4Gd8IOT+MvBSid9UeBtJJTj9IMC+s/KDtXKoQ9WHLtLtAB2RrlPP+24uE5ffUoY/VX/9z9/BYFmtzu526ezkuV5BrNH457DhPcKvor/HXfFNxQmnxqMuG75TBT2jFMfv3PVVtAJuibqTJPygq0tJSjYSxtETRWCK3CveIkMPlemsFdPJWHzNuLydhTEvKyfao5fCEUHS2es301T0bjNjzCw+egtTyUc1KQisf8SILrnoy/gDJiT/txG0+W2iowoNlEaC9GpG1Z7c+kG3OiiyounfHSGV53iQ5BhSTLBCnAF0FN/aZOlaa/dNx+13guEAploz4ZJLvYgje1ViBjQFPdZwmmDQJodTyiP7uBn1NXPdICDjT2Nsne4GFU8mPAOeexkiIeaY8G1xff4iP+P7dXtSC5moINnJmYmn2SQ7p8YDpB2GTlewXgvn6Jlhk9y0Kx/EQiU1yyYTZQHxrMjJdMqt/5NMkE3m2aoxBZnaba1P4LbpoXmNgA7TdtG4cOdYb6NnJ7Mznfeqgp3S+QNksa4mM2hBQts4fjAXiRwI75YdIMPaECFWQGRHXufjtLe8yyiNJsHKDTPOFCOW0eJZUwjfEnqVmClV9BOnv6lwExGEV0M2y9IwgKTuw5Wmn9Q7CAuc2iUk/g8e8bEx2olSz38G5ntfLL+UPCcOTna0b6bduYYRryAZP8JF0YLSC8tsQLh51YfOejiTZreD+h4BBjPSh4BvTRl8lqFxx7IjdIyYvNNJYuV4s0NRD20S++Un+VWT1FSfczAFGuyTng6KQcUYUOqj3z/7sMUKOrT24Hld3HTRgtmU+EY3G71BckZ3cvOXtZcpbD+M5B1b4UNXfwuoh/uIfEU6aogBSTuwjHzsPbQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_24902737EE4046E8B62FA5B7C449198Bciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3174.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eb8576b9-ff87-400b-15d2-08d944440583
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2021 08:15:18.9068 (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: FGbvYmC3YHYogpR3awbDDL8PqsRi/jR1PgVkTAdYan6R9VnLQeEn1GHrZbbnQedokHeX+iLXoNwtT7VKpsCbMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4149
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/NouFbkm-d-6x1hAetRvNiWlKNw0>
Subject: Re: [Last-Call] [EXT] Yangdoctors last call review of draft-ietf-rtgwg-qos-model-03
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Jul 2021 08:15:31 -0000
Hello Jurgen, Sorry for the delayed response. Please find the comments inline with prefix [A] We are updating the draft based on these comments. Regards, Aseem From: "Aseem Choudhary (asechoud)" <asechoud@cisco.com<mailto:asechoud@cisco.com>> Date: Sunday, May 2, 2021 at 11:08 PM To: "yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>" <yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>> Cc: "draft-ietf-rtgwg-qos-model.all@ietf.org<mailto:draft-ietf-rtgwg-qos-model.all@ietf.org>" <draft-ietf-rtgwg-qos-model.all@ietf.org<mailto:draft-ietf-rtgwg-qos-model.all@ietf.org>>, "last-call@ietf.org<mailto:last-call@ietf.org>" <last-call@ietf.org<mailto:last-call@ietf.org>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>> Subject: Re: [EXT] Yangdoctors last call review of draft-ietf-rtgwg-qos-model-03 Hello Jurgen, Thanks for your comments. We will address these comments and update the draft. Regards, Aseem From: Jürgen Schönwälder via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> Sent: Tuesday, April 13, 2021 6:27:33 AM To: yang-doctors@ietf.org<mailto:yang-doctors@ietf.org> <yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>> Cc: draft-ietf-rtgwg-qos-model.all@ietf.org<mailto:draft-ietf-rtgwg-qos-model.all@ietf.org> <draft-ietf-rtgwg-qos-model.all@ietf.org<mailto:draft-ietf-rtgwg-qos-model.all@ietf.org>>; last-call@ietf.org<mailto:last-call@ietf.org> <last-call@ietf.org<mailto:last-call@ietf.org>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org> <rtgwg@ietf.org<mailto:rtgwg@ietf.org>> Subject: [EXT] Yangdoctors last call review of draft-ietf-rtgwg-qos-model-03 Reviewer: Jürgen Schönwälder Review result: Not Ready - You may want to align the document title with common popular titles, see https://en.wikipedia.org/wiki/YANG#Standards-track_data_models, e.g.: A YANG Data Model for Quality of Service (QoS) [A] accept. Perhaps it also makes sense to expand the abstract a bit. What is the difference between 'configuration' and 'operational parameters'? [A] I will update with current scope. - What is a 'data module'? We usually have 'data models' and 'YANG modules'. [A] fixed it. - There are language quirks (e.g. missing articles, singular/plural confusion) that someone should look at and fix. An example: [...] Differentiated Services (DiffServ) module is an augmentation of the base QoS model. Remote Procedure Calls (RPC) or notification definition is not part of this document. QoS base modules define a basic building blocks to define a classifier, policy, action and target. - There is always the question of how many modules does it take to do something. [A] We have created framework and way to extend it. The Policy, classifier, action and target modules can be used for any QoS extension, e.g. for L2, MPLS etc. It also can be used for different ways QoS is implemented by various vendors in different market segments. - I find subsection 1.1 weird (I dislike one sentence (sub)sections from a stylistic point of view), simply move the statement into the section where you define terminology. Well since we are it, I am surprised that there is no content specific terminology defined or imported. I assume you want to import basic DiffServ terminology from somewhere, perhaps other terminology as well. You obviously assume that people know what a classifier etc. is. - "A classifier consists of packets which may be grouped" What? A classifier consists of packets? Please import definitions instead of making up your own ones. RFC 2475 for example says: Classifier an entity which selects packets based on the content of packet headers according to defined rules. - "A meter qualifies if the traffic arrival rate is based on agreed upon rate and variability." What? RFC 2475: Meter a device that performs metering. Metering the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes. [A] Adding terminology section and updating there. - "This module imports definitions from "Common YANG Data Types" [RFC6991] and "A YANG Data Model for Interface Management" [RFC8343]." What is "this module" referring to? There are several modules. Do we really need that many? Should the decision to break things in to rather small pieces be justified somewhere? [A] It meant “ietf-qos-action” module. I will fix the wording here. In general, the statement about where definitions are imported from is in the modules sections, not in the terminology section. - There are a number of MIB modules for DiffServ and it might be useful to explain how the YANG modules related to the MIB modules. [A] ok, sure for the diffserv module. - The module names suggests that QoS == DiffServ, which I am not sure is necessarily true. Given that these modules seem to be DiffServ specific, it may be better to use the prefix ietf-diffserv- instead of ietf-qos- [A] QoS is framework, Diffserv is using QoS framework. Similarly, it can be extended for L2 and MPLS. - The authors should consider their naming scheme. Repeating words in identifiers makes instance documents verbose and hard to read: <classifiers> <classifier-entry> <classifier-entry-name>foo</classifier-entry-name> <classifier-entry-descr>some foo</classifier-entry-descr> ... <classifier-entry> <classifiers> vs <classifiers> <classifier> <name>foo</name> <description>some foo</description> ... <classifier> <classifiers> [A] This is improved. - In section 5 first module, you should explain where the filter entries are coming from. Apparently the idea is that the filters are augmented in but that should be explained. - It might be useful to explain which features are defined. - Why do you label some rw objects as -cfg? Is not everything rw here config? [A] Right, this is not required. I have fixed it. - Why is a classifier-action-entry-cfg associated to a classifier and not to a policy entry or a list of classifiers? I do not recall enough about DiffServ to recall the underlying model, it just feels a bit inflexible. [A] Every classification in Policy has some associated actions. - You seem to be inconsistent with nodes for lists. In ietf-qos-classifier you have +--rw classifiers +--rw classifier-entry* [classifier-entry-name] but in ietf-qos-policy you have +--rw classifier-entry* [classifier-entry-name] - Named meters are called meter templates? Named classifiers are named classifiers?? [A] For uniformity, we can rename it as classifier-template. - Should ietf-qos-target be renamed to ietf-interface-diffserv and should it not be augment /if:interfaces/if:interface: +--rw diffserv-policy* [direction type name] +--rw direction identityref +--rw type identityref +--rw name string instead of augment /if:interfaces/if:interface: +--rw qos-target-entry* [direction policy-type] +--rw direction identityref +--rw policy-type identityref +--rw policy-name string [A] “policy-type” -> “type” and “policy-name” -> “name” will be fixed. Since it can be any qos policy type, “qos” will be better fit instead of “diffserv”. (Also note that I added the policy name to the key!) Of course, if one would assume that names are unique across all policies, then the type leaf would not be needed but you seem to assume that it is a feature that I can have multiple policies with the same name and different types. [A] This is correct, names could be same across types. - Why is this: "Any queuing, AQM and scheduling actions are part of vendor specific augmentation."? [A] AQM is very implementation specific and difficult to generalize. Queueing and scheduling are well defined and accordingly I will fix this statement. - It needs to be clear how filters combine. - Should some of the lists that have a single leaf be turned into leaf-lists? Or is the reason to enable augmentation in those lists? [A] It is done for uniformity since most of the list contains more than one leaf. Some can be converted to leaf-lists. - Calling a leaf -addr but using inet:ipvX-prefix is inconsistent. I think you want to use inet:ipvX-prefix and hence you should adapt the names to source-ipv4-prefix etc. [A] correct, prefix should be just fine. - I suggest to not UPPERCASE the module names in section titles. [A] Sure, I can do it. - Copyright says 2019 - time to move to 2021... [A] indeed 😊 - I am not sure I understand feature classifier-template-feature from the description of it. I am actually lost on the possible combinations of policy-inline-classifier-config, classifier-template-feature, match-any-filter-type-support, perhaps because the descriptions are messed up. [A] I tend to agree, I will try to fix it. - Please try to pick good names. I find 'classifier-entry-filter-operation-type' overly complicated. Perhaps 'match-filter-operation' is better matching the derived identities... I guess I would even go for filter-match-operation +- filter-match-all +- filter-match-any Finding good names is hard but matters a lot. [A] yes, this seems better. I am lost on the match-any-filter-type-support, why is filter-match-any a feature but filter-match-all not? [A] This is because, typically all vendors support “match-all” but some also support “match -any” - Descriptions need to improve. Some have language issues, others are simply too short and not very descriptive. I think we like to have full descriptive sentences in standard YANG modules. [A] Sure, need to improve. - I do not understand filter-logical-not. This seems to negate filter-match-all and filter-match-any. But what do the combinations really mean? I assume 'not any' means none, I am not sure what 'not all' means, perhaps 'any or none'? Why not simply add another filter-match-operation, e.g., filter-match-none? [A] so it will be like this for the whole rule with “match-all”: “(source-ipv4 1.1/16) && (not dscp 4-40)”. This rule will match on source ipv4 1.1/16 and (dscp 0-3 OR dscp 41-63). Similarly, the whole rule with “match-any”: “(source-ipv4 1.1/16) || (not dscp 4-40)”. This rule will match on source ipv4 1.1/16 OR (dscp 0-3 OR dscp 41-63). - Why do we need two groupings for named and inline classifiers? If we need two groupings and they are only used once, why are they defined as groupings? Why do I need this classifier-entry-inline boolean? What does it mean to have this boolean set to false in an inline classifier?? [A] This is mainly because inline classifiers are used in policy only and applicable if “classifier-inline-entry” flag is set. - Why once classifier-entry-filter-operation and then classifier-entry-filter-oper? Why is the inline classifier defining the list filter-entry but the named classifier is not? Perhaps there are reasons but then they should be documented. [A] This is because list filter-entry is defined where named classifier grouping is used. - I am not sure about the choice of prefixes, but there is perhaps no consensus on how to choose prefixes. That said, prefixes like "target" seem rather generic (but as long as others do not pick such generic prefixes...). [A] I agree. - Do not write "Latest revision for qos actions" if it is the initial revision. Ideally, revision statements do not need to change when a new revision is created. If you write 'latest revision', well, you have to go and make changes. [A] Ok. - "This feature allows support of meter-template." OK, but what is a meter template?? How do the features meter-template-support, meter-inline-feature, meter-reference-feature interact? Can I implement meter-reference-feature without meter-template-support? Does it make sense to implement meter-template-support without meter-reference-feature? The descriptions do not really help in describing things. [A] The reason was for vendor extensibility. Some vendors use meter templates to define packet coloring without referring it in policy. In the strict sense of the base model, it can be same feature. - Is there a way to reduce the number of features? Is it possible to define a baseline that everybody commits to implement? Client complexity grows quickly with the number of possible feature combinations. [A] Some of the advantages are lost in a single baseline. Like above, an inline meter vs meter template, there are benefits of each. Some vendors have started supporting multiple ways to reap benefits of both. Hence, it make sense to define these as features where some vendors have already supported, some may plan to support. The validation can be done in the backend without defining features if that is the norm. - For some of the groupings, it is not clear why they exist. Where is the grouping drop used? Oh, you refer to it using action:drop in the appendix, i.e., its only there for extensions?? [A] “drop” was added to be used by any vendor supporting it even though not used in the model. In the true QoS sense, it can be avoided but sometimes there is specific use-case and some vendors support it. - I am not an expert qualified to check whether the various meter-action-params make sense. This should be verified by people in the WG. - What does priority level 7 compare to 8? What is higher and what is lower priority? [A] Agree, need description improvement. - Putting the description statements at the end of nested container/choice/ case definitions looks pretty weird since you get a sequence of closing curly braces with descriptions. - You seem to support an inbound policy and an outbound policy. Can there be more? I am asking since you use a construction with an identity. If its only inbound or outbound, you could instead simply do inbound-diffserv-policy +-- type +-- name outbound-diffserv-policy +-- type +-- name and if the names would be unique this would further reduce to augment /if:interfaces/if:interface: +-- inbound-diffserv-policy string +-- outbound-diffserv-policy string [A] it can be possibly “both”. But, it will still be a list either way. - You probably want to look at all places where you have name references and detail what happens if the names do not resolve to something. Do you require referential integrity or will policies not be applied or applied in a different manner if referential integrity is not given? [A] it will be based on implementation where it could be backend validation failure in some and some vendors support forward reference. - I just now realize that qos-target-entry is a list. So I can apply multiple inbound and multiple outbound policies. What is the result of this? [A] Right, based on the type. Again, it is based on architecture. E.g. in VOQ architecture, Queues are effectively on ingress node and marking on egress while in some cases there can be marking first and then queuing. - The source and destination port groupings have a reference to UDP and TCP. Does this imply that these groupings do not work for DCCP or SCTP or any other future transport protocol using port numbers? Perhaps simply drop the reference and rely on the type definition. [A] Somehow, I don’t see TCP/UDP reference. These groupings work for any protocol and not restricted to TCP/UDP. - I wonder to what extend protocol number ranges practically make sense, but perhaps it is OK to keep the ranges for consistency. [A] Right. It is unfortunate that we do not have an inet:protocol type defined in the ietf-inet-types module... Your definition talks about the 'upper-layer' header but I think there is no such thing. I understand what you mean (ignore all extension headers) but the text seems to be referring to something that does not really exist. [A] Right, the wording needs correction - Is it possible to reduce the duplication of the filter cases for named classifiers and inline classifiers? The constraints on both also seem to differ. [A] - It seems some of the complexity of the model comes from the attempt to be extendible and in particular to support vendor extensions. I guess it would have helped me a lot if the introduction would have spelled out what the objectives of the data model are. There is a lot of reverse engineering going on in my head and this is painful. It would be much simpler if the document would have stated the objectives of the model. [A] We would try to be more elaborate. - I did not run any compilers etc. but I think this is fine since the modules are not ready anyway. - IANA considerations missing. - Security considerations missing. - The MITRE approval is funny given the IETF process and the note wells around in every corner. - The text refers to [RFC3289] for the diffserv architecture but given that [RFC3289] defines the MIB module, this seems somewhat surprising. [A] Yes, need correction - Why does this document need a normative reference to RFC 6020? Why is RFC 6020 referred to in a revision statement?? [A] - I ignored the extension examples in the appendix. [A] ok. - I wonder, has someone tried to implement this? Or is every vendors doing his own thing anyway and this is more of a standardization exercise? How does all of this relate to say the open config model? OK, ignore the last question. ;-) [A]. There is some work in progress where oper model is being used which in turn depend on config model. Some other vendors may be using it as well.
- [Last-Call] Yangdoctors last call review of draft… Jürgen Schönwälder via Datatracker
- Re: [Last-Call] [EXT] Yangdoctors last call revie… Aseem Choudhary (asechoud)
- Re: [Last-Call] [EXT] Yangdoctors last call revie… Aseem Choudhary (asechoud)