Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt

"t.petch" <ietfc@btconnect.com> Sat, 07 July 2018 11:28 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B46E130E05 for <ccamp@ietfa.amsl.com>; Sat, 7 Jul 2018 04:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 ecrG15ZG7Qgv for <ccamp@ietfa.amsl.com>; Sat, 7 Jul 2018 04:28:47 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0121.outbound.protection.outlook.com [104.47.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546BD130DFD for <ccamp@ietf.org>; Sat, 7 Jul 2018 04:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VupGxUQPno+oj9NFs0TNKY3ybk2fqSPJbU3/xwuD5Uc=; b=kCpVStG2zT67ZyMIH4QF/nJ5EkPz0pAi1YuB4aAaAmr3aVULFui98F/xmAFYJ4T/TL0+woPzZnaiqsKTaWBbRU5oMuzx84RoMYcju2gzPr9gQH6W61mjCCIM5uFVY4dD8GuU24Khy6zsThx112GaFz+3YSB8rR70baORd+qVjXo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
Received: from pc6 (86.156.65.243) by HE1PR07MB0828.eurprd07.prod.outlook.com (2a01:111:e400:5126::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.16; Sat, 7 Jul 2018 11:28:42 +0000
Message-ID: <021401d415e5$4fa38e80$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Leeyoung" <leeyoung@huawei.com>, <ccamp@ietf.org>
References: <152962050398.31812.6467603772771193083@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E173D01BA77@sjceml521-mbx.china.huawei.com> <024a01d40b2e$3899ed40$4001a8c0@gateway.2wire.net> <001701d40d6b$1a330500$4001a8c0@gateway.2wire.net> <7AEB3D6833318045B4AE71C2C87E8E173D0212C8@sjceml521-mbx.china.huawei.com> <01e901d4137d$43ac6bc0$4001a8c0@gateway.2wire.net> <7AEB3D6833318045B4AE71C2C87E8E173D021B92@sjceml521-mbx.china.huawei.com> <041101d4151e$915a3f80$4001a8c0@gateway.2wire.net> <7AEB3D6833318045B4AE71C2C87E8E173D021EFA@sjceml521-mbx.china.huawei.com>
Date: Sat, 7 Jul 2018 12:13:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.156.65.243]
X-ClientProxiedBy: DB7PR08CA0007.eurprd08.prod.outlook.com (2603:10a6:5:16::20) To HE1PR07MB0828.eurprd07.prod.outlook.com (2a01:111:e400:5126::26)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 6ce835f7-08a0-45bc-8bd0-08d5e3fccba5
X-Microsoft-Antispam: UriScan:(219612443155931); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:HE1PR07MB0828;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0828; 3:ACB2N/vZrsrjVnlOL/sbFmEQkQwJNFH7Fd5DPnvfebvuCnD/mGkm/BIEhYIXe+B39tFwo7sge+qgcbZC5uzDtHiQYDV+uWq5u6Jnea77Mztyeg7vEIHSkcbv/LhEOSRUAWDwE3+Do7EiuWbBPcwdmnD62O6FpAnUSsEvQWCugmKs9/odahBqZZXv7ypudk7jG9xDSojokhTNv+rmZCYXGGuwUNS1Lu/1RfEZkuSCckXUsbyADfw9BgpyCdK7awj6X00E294HpFDhsSrjCTNMMXlaJo/jK898wOSw59H9fQU=; 25:kl9Eac+Dppe0op3u3P1a6VD6gjrsUqz9D9jEe7eobbxC7d+fFxu0oGww7e1q2lF1UDKKfS5I8vtuvPXdM6Dn/KbkoEs+Yo/vbFxYZeehlmHmJMDnSCSBBw1lYFKn0dULLVp1B+gcVGRTxSDkuyyC4WemQjNdoiGy0z6j3C8465V/SDagudA+nTeHwqVtMME2n3vbJu789F7NkAJ0uFOYZed1+/DJ2hO9AstgFXeog264Odf4wBbqdQI0yFIyA9N7wqDDuxlPF5p1CiXXywg3VMzqUnTLjUy6zPIXdja17hL7wTKKRP73Pv73faXFFF2CcKRZM5Ecejj6N7p5q1Yfuw==; 31:f/Ya10HSxQtdpCbfJr02U6tn7BgLmPr5t+XBjJBBfogrno9uB2QaBUTbgQyorngWAf2VR8WP1KhTY7ApBDO1tCBHFarhqiIXuvLHifKifYZRXfIHO8OgE0GHf7M9b3AHS8n5n6KhCA617LR9eIoPIYLi0K4r+7MGOykx4iaSWzI9amhbgvP+Wr9STnDe1MqDA4RVIK85/0n6n9KflnHfhLaa6yBFHpp1cr2qrwNJ5w8=
X-MS-TrafficTypeDiagnostic: HE1PR07MB0828:
X-Microsoft-Antispam-PRVS: <HE1PR07MB082813956536B674C87FEAF1A0460@HE1PR07MB0828.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(158342451672863)(120809045254105)(192374486261705)(50582790962513)(219612443155931)(788757137089);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:HE1PR07MB0828; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0828;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0828; 4:TUT3QuPGSwUPsz9gTyH1mdR4nutmV0tobgFBPmEpQlSNqHS3++xBq77ixbZi6ZSzdoQojvOZpZJFvZutPp6wbDfnP9PK562/xuET35oTTkT/dPeH11GnpIWTm5nl8EouBjAQu0duKVJOmbevqB0aAzxfq4eFmyso8uhkbCK14Xw5+HOhFAsC4MjvxQ7JAJGATLlI86ftBQy5BpVXCfgz+yrq+EELT/IJ6EQVeufYtxsCI3L+NMEXzqNUI7Dfz8nuCqet9na8QFoCVmXZorue0t62iIOj0EuCh0FK+5px19MamgvGHnky8alHElA3WmbAUzxiCh+ld/Qmy/wLGH1wxZbEfRIazEidrCqu+Sx8rBkLQpUOGckh7VNr6JAk0LEKX4w5GE2s1UjoySlPsgXmLKZb8TQYsAtyQxTxzS3NEKt+9CTVzcRsTpwpqvYij65IGKnPzDv8v2vycOBEHFvJHK7sqNOaNT7bYdQ5/eWPH8HraXr8Wnwv3/4CW0TDQYPCj73SAM8y+M2IyMkS9+Kvwg==
X-Forefront-PRVS: 0726B2D7A6
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39860400002)(136003)(376002)(346002)(13464003)(189003)(199004)(51444003)(5660300001)(66066001)(6666003)(2906002)(16526019)(4720700003)(50226002)(81156014)(8936002)(9686003)(62236002)(81166006)(8676002)(105586002)(61296003)(25786009)(47776003)(14496001)(106356001)(305945005)(956004)(50466002)(53936002)(44716002)(446003)(476003)(5024004)(97736004)(7736002)(14444005)(486006)(33896004)(229853002)(44736005)(76176011)(81686011)(26005)(966005)(81816011)(86362001)(316002)(52116002)(3846002)(6246003)(6496006)(186003)(110136005)(478600001)(6306002)(386003)(68736007)(6116002)(23756003)(53546011)(93886005)(230700001)(84392002)(6486002)(1556002)(74416001)(7726001)(473944003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0828; H:pc6; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB0828; 23:xsrzhtqfOoM+3+CpK/wZJBlKzsDEnG4qlgws9YG?= =?iso-8859-1?Q?8v8cjzCgE9Vozk3bv+zZYpI4UQG+51BtQYUL2uYKqucAKnUSTjlr+JY4Gh?= =?iso-8859-1?Q?1Y1ZqZweWMy/I1+JI/L34YDhK41SRjsPEfpbnHOKNjAhrBZ7PZs6qf0o4d?= =?iso-8859-1?Q?QowQJG8vFqUWsgkD3Pd5a9y3xAk/fluZqhRgH5Ehizcw7LllCzX0Drr4fE?= =?iso-8859-1?Q?fT3zJfmqY1LitHu8CF7Do5W6qzUFyfxcEnTLgCpiEKbRy/w4O7Be7NJsxf?= =?iso-8859-1?Q?TFNlhcEUms3jIuRf7ho4/JDRgtOhlCBc4E4pBdtAcijIj3owzD8cSOMAjK?= =?iso-8859-1?Q?nrv9LkeVAKOJInl8kZB8Bf8VZMAYTUjOS73PLmmOAy7ODmQIEk5HhZcStq?= =?iso-8859-1?Q?jcl/HPyN2Aq28HCiGIKHDYaQGwTIaLQjaJWEIHb2qPiqXfLfSx3eOVCLRe?= =?iso-8859-1?Q?TNXJ2xHTqn52rySBf2eeDq5oiq14SJqviCvx9SB9QTd9GGwjXF5lVw+GuP?= =?iso-8859-1?Q?EtrlxJ9iOO1aaURnpSEEqQEsOKSCJ6wNtKtyqPQA6w96H/dQvOoVxydFQp?= =?iso-8859-1?Q?/luaYuQZ7ep46yBxfW7Ubin3qJnBu3wECjaivLgKRhJMXUNzGg8yLtFWXH?= =?iso-8859-1?Q?toegqju2K0MDc6UNkxGzuFrgvEQl62qJX8xMTK6mdyiHjdgdktGhjxzV41?= =?iso-8859-1?Q?0HhMDIBnYaaUcVyLbKIcQ+W7uqoF3Lqg/NX7MYYGK8LkYo0LnrnSjv/IDr?= =?iso-8859-1?Q?88MvBH9lTT5C4pZw8Hk+NAJZD4cFGEW5zumrh+1Q334MJqwuESmOaZ+9L9?= =?iso-8859-1?Q?XCgF7d4WF3Shr1y3Uc9du/NSGmAwD7hGjO87cProbBVtJ+rVAQLtVW9e60?= =?iso-8859-1?Q?m8mxvJ0Ykrz4cR4PIijZt1sCSetOY9aH5LtSzixlnXoGQdJiqaUEMlZHdR?= =?iso-8859-1?Q?ivelI0GKAaou3Vz+2o5K7GO+lUwhv8zDI7iyiv9hezJzkiNJXjv2WinRis?= =?iso-8859-1?Q?GV/AnSMDjtuB/38QMKR+kTErULB04nSFeUyBCNumc4c9VkLxb6+izOxp/R?= =?iso-8859-1?Q?E+AORU3JrUeO2TVE44K+ADl0stf90A5B/YkjYuRJueD8e5ztRzHPlpal/a?= =?iso-8859-1?Q?k0z54G4DFdDcMJVCnuJ4wXkiiSnaB6Aicjmcqmc/2jRt7dHMBporEDS8bE?= =?iso-8859-1?Q?k+/JfNS1Ntp2jZwUj5pXDf07RbOGz70fzpypaw8tcS8k0bAphw88Ip7+1G?= =?iso-8859-1?Q?1Ye6tWkrHGiqG61Zye0JyNCDvEy3d3UlWqKA2UhV+P9FG0q9nvqGlNiTQi?= =?iso-8859-1?Q?0XLjHAJttnglunEPW/UBi+6sJSWDeHcJXU4O8eokdYax1iiN0ppVSME/16?= =?iso-8859-1?Q?XmHF2Ogr+pZfOXKvRLq2III/lmdjUnwtvFdeFRajxerFoCpyiBtBpFFYlV?= =?iso-8859-1?Q?pcRuL5fXXxNUMnXcm0hYRpdz1FyQwUDWOC+I8q3myo58WruSvnQ0kExNru?= =?iso-8859-1?Q?WYare5KdLN8W0LL+vojJwnePLt95tbcAfJYF3u51uUScV+6jpL55MUXwos?= =?iso-8859-1?Q?QaZiqpquHXnAshlot2U1SlLtMf/LzjvVJufwLR094PFQ/tD80Qgf/5lXAW?= =?iso-8859-1?Q?hd4SLn8M20SS9HVsBrdKaXWLnsgSB8ZY=3D?=
X-Microsoft-Antispam-Message-Info: iHDMcaOdQkf605ICx0cM5nFQ8bGmEwTUtmEbDUcNWqaQ/lmPpq0B+1RkwJ1eX8JjeXnMwUnQzCEp9ideqBa7B1dHQoJ9JbWjfHmPtq7xpd0dTvGbT21C8O1KikkVqjYE+sKzRMYPK1svcb3lBDgPgzthbqUGwfW+o/W6HWLTMFdOKFRH2khGaa39+6/1OTMI8cyGfT3dLlTb+kMM1qfxr/3u34tXBX8t2xN1dCxJ0ouKcsOuo1MFwenosY3cHhXSPsJeHVAe9gzp+YtM8vEu5s3edBMbjuTmr0m7K7xjLd8IdpOVmg/yRG32OBztJ72DNcZYK1SS5OR5MygyTn8U+d9VW2WBhWiqhNdkQpcyO2s=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0828; 6:+eoCpiOSWxHaWcK6tm3OMh0UgGEjt4ufT73sNP5j9+Z+4LDc8fF5iUvuN92C0nP1/30eUAekPgIw6pjOjPXahrB5VmvQFluIePwMYSxQk5dsZRJIwzeCLHS81Q9m/ClmZ5n+2cSNx40ET/h+s/PfUV2fgfESL3hSiNT/VQwPLqjO7kXnjAAmfUsnLkE6eDHbU8+w2s5DjgwsI5VBnVhwDAaNAyig5AEUNs/tYx9qMlxW6sfUx4kjK8YPEFIHi3EHPnXcC722ItonBqaRAQaHuNmsTiWxK6l4RYu8MrpWPPUmT7jMwX852nii9Qrvu/jLiD+LMTOR7eCpb+phmiZWDlLtQ54KT5D/ZXkpDFz7pJCngaf8QIXoiHa8Ku9yGSQ4b3S1IaJIIJojTjxSVMeG2Jo1KpgBd3+XVuA0+A80w4zT3P0g0hJvFy3s/S2O3bwvrXNwE5rkveZu4Ysn1utkpA==; 5:CMEpHeHyy3ZFYICjfhnpQV7cuxTgOvs7TbTUxDHBn2qQzQNK8rPzAVg6rBxy5O1+froFUd5ZqS/7KjhwJl3l6Vkv4NmGeJtl+i2VmSolhaPltOngYue5hfAvaWexMDjH42GHekY1Lmb0neX/324mu1buKhb1A03v24aJkPc8K3A=; 24:2eu/LXweBM5YLcT2xe5vfMIDL6hAq2Jnbmb5x/WIikxW4gDoXPnkFJaMviN5bQ8ERxnZRuo677nKbPgSeqBVl2ccau/AW51Hn5Tece++HoU=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB0828; 7:wMI1VJYQ/CY6h8TCMwDI+XPXyHtmzbwcTgdIs2vEkhgCZBHUZSSX46sy5ilw/Pk27Dd1jc6RKINgVLBJ1Eavx3s89hlnr5PdtrRIojaqthxUCkCrkWK7cgfIAs2xBXisXgi1zcOZRh6z+F9TzrtRKRhQQM8khIobup0namByla4EsTxTtOSNS8OZ1lMSROy9SGIjbcFw73beiqgPNA9EHJLr97b1+gI3LnsrTF0kjuoLDhlr9BJugiyQ4CYdRpau
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2018 11:28:42.6297 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ce835f7-08a0-45bc-8bd0-08d5e3fccba5
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0828
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/oDp7lTm7KA46DWd7q_Gct-pYRD8>
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jul 2018 11:28:52 -0000

OK

Tom Petch


----- Original Message -----
From: "Leeyoung" <leeyoung@huawei.com>
To: "t.petch" <ietfc@btconnect.com>om>; <ccamp@ietf.org>
Sent: Friday, July 06, 2018 10:39 PM

Hi Tom,



Thanks for your further comment and clarification.



Please see inline for my comment.



Best regards,

Young



-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]
Sent: Friday, July 06, 2018 6:15 AM
To: Leeyoung <leeyoung@huawei.com>om>; ccamp@ietf.org
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt



Picking up on the MEF reference, what I mean is that the lime I-D I
referenced has

   [MEF-17]   "Service OAM Requirements & Framework - Phase 1", METRO

ETHERNET FORUM MEF 17, 2007.

which identifies a document to me which is my point; it is not a
question of access, it is a question of identifying reliably what it is
I want to access and I do not think that your current text does that.





>> Currently the relevant MEF reference (L1CS Attributes) is in the form
on Working Document
https://wiki.mef.net/display/STA/2018Q2-SC-Contributions?preview=%2F7261
5217%2F77629004%2FS65015_003_Subscriber_L1_Service_Attributes_Tech_Spec_
WD_v0.15_Martin.pdf .  This MEF reference is about to take Last Ballot
in Q3 MEF meeting in July. Once it becomes an official MEF document, we
are going to update the MEF reference similar to what you show above for
OAM requirements & Framework.





One more issue for the moment, on time interval again

      leaf time-interval {

        type int16;

        units seconds;

        description "a time interval (e.g., 2,419,200 seconds

                     which is 28 days)



Time intervals generally raise a number of issues that need
consideration.



Should there be a default?  There should if one is in widespread, and
sensible, use.  Here I do not know but think that the guidance you have
in description is likely enough.



>> We can make 28 days as a default, but this need to be agreed by the
WG.



Should the range be limited?  Is zero a sensible value? I tend to think
of a hundred of something being the minimum for sensible statistics and

1000 as better so if we are talking about e.g.

One-way-Errored-Second

then we are talking of hundreds or thousands of seconds so I think a
minimum worth having.  Maximum? not sure; I tend to think in hours
rather than days and you clearly see a month as sensible.  Needs
thinking about since later reviews are likely to query this.



>> I am not expert in setting ranges for min and max for time-interval
for performance monitoring. I would leave this to be discussed by the
WG.



Again on a minimum value, does having a valid too low a value open up
DoS attacks?  This is often called out in Security Considerations after
secdir have complained about the possibility!  Again, needs considering.



>> I would leave this also to the WG discussion.

Tom Petch



----- Original Message -----

From: "Leeyoung" <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>

To: "t.petch" <ietfc@btconnect.com<mailto:ietfc@btconnect.com>>;
<ccamp@ietf.org<mailto:ccamp@ietf.org>>

Sent: Thursday, July 05, 2018 5:58 PM

Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt





Hi Tom,







Good to know it is getting there! Thanks for your further comments.

Please see inline for my comment.



The actual update is now frozen; so it will be done during the IETF week
once the update window is re-open.







Thanks.



Young







-----Original Message-----

From: t.petch [mailto:ietfc@btconnect.com]

Sent: Wednesday, July 04, 2018 4:56 AM

To: Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>>;
ccamp@ietf.org<mailto:ccamp@ietf.org>

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt







Getting there!







Abstract



The IESG have takent to asking for something of the like of This YANG
model is NDMA-compliant.



at the end of the Abstract







YL>> OK. We can add "This YANG model is NMDA-compliant."







1.Introduction







NETCONF gets a mention but, as Security Consideratons says, RESTCONF is
also an option in which case I think it should appear here (unless you
think it inappropriate in which case I also think it should appear
here!).







YL>> Agree.







1.2



   The terminology for describing YANG data models is found in



   [RFC6020].



Nope try RFC 7950







YL>> Thanks. Agree.











YANG terminology is a mess at present.  RFC8342 has redefined some terms
and not others so that draft-ietf-netconf-nmda-netconf just references

RFC8342 and says no more; that RFC does define







o client



o server







but does not define







o configuration data



o state data



o augment



o data model



o data node







I think that the best you can do for now is to reference RFC7950 and
RFC6241.







YL>>  Agree. It looks like: RFC 7950 defines: client, server, data

model, data node, augment; RFC 6241 configuration data, state data.







You need a Note to the RFC Editor asking them to change the date to the
date of publication in two places in both modules - by that time, there
should be only the one revision clause in each module stating 'Initial
Version' although up until then, you go on inserting clauses for the
different versions of the I-D; I would still add the Note now.











You need reference clauses in the YANG module - having references in
Section 1.4  is not enough as the YANG module has to be complete in
stand alone ASCII - see how



    draft-ietf-ccamp-mw-yang



handles this







YL>> OK. I will add that.







      leaf time-interval {



        type int16;



mmm I do not see how int16 can count up to 2,419,200 ; int64 sis seem
excessive but I think that int32 is needed







YL>> Correct. Int32 would be good.







Since



'one way severely errored second'



is the ITU-T term, then I think that you should have the ITU-T reference
direct and not expect the reader to think of looking to see if it is in
the MEF reference







   [MEF-L1CS] "Subscriber Layer 1 Connectivity Service Attributes",



             Working Draft (WD) v0.09 December 13, 2017.



does not enable me to locate the document;  MEF suggests MEF but I would
like more; look for example at how



   draft-ietf-lime-yang-connection-oriented-oam-model



handles this







YL>> I still disagree with this. I try to avoid "double referencing".

Besides, there are more than 20 references from ITU-T, IEEE, ANSI and
Telcordia if we were to be comprehensively referencing. I'd like to
defer this issue to WG chairs. If your company is a MEF member, you
should get the document from MEF wiki. If not, there should be ways to
get you the MEF document as MEF initiated a liaison with IETF/CCAMP on
this work.







RFC6991 is an import and so needs to be a Normative not Informative
Reference for the I-D.







YL>> OK. This is fine.







I have yet to go through the YANG modules in detail but it will be a
while before I have time to do that..







Tom Petch







----- Original Message -----



From: "Leeyoung"
<leeyoung@huawei.com<mailto:leeyoung@huawei.com<mailto:leeyoung@huawei.c
om%3cmailto:leeyoung@huawei.com>>>



To: "t.petch"
<ietfc@btconnect.com<mailto:ietfc@btconnect.com<mailto:ietfc@btconnect.c
om%3cmailto:ietfc@btconnect.com>>>;

<ccamp@ietf.org<mailto:ccamp@ietf.org<mailto:ccamp@ietf.org%3cmailto:cca
mp@ietf.org>>>



Sent: Tuesday, July 03, 2018 4:01 PM











Hi Tom,







The draft has been updated yesterday. Please see
https://datatracker.ietf.org/doc/draft-ietf-ccamp-l1csm-yang/?include_te



xt=1







See also the attached diff file that compares versions 4 and 5.







Please see inline for my specific comment to your comment. Let us know
if there are any other concerns you may have.















Thanks.







Young







-----Original Message-----



From: t.petch [mailto:ietfc@btconnect.com]



Sent: Tuesday, June 26, 2018 11:31 AM



To: Leeyoung
<leeyoung@huawei.com<mailto:leeyoung@huawei.com<mailto:leeyoung@huawei.c
om%3cmailto:leeyoung@huawei.com>>>;

ccamp@ietf.org<mailto:ccamp@ietf.org<mailto:ccamp@ietf.org%3cmailto:ccam
p@ietf.org>>



Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt















Thanks for fixing the indentation; much easier to comment on!















Two major thoughts.















First, how attached are you to l1, that is letter l followed by digit 1
?  I know it makes sense but I also know many contexts in which that
would not be allowed because the probability of confusion is so great,
with the digit being read as the letter i or letter l or the letter
being read as a digit  or ...  I think that this needs careful
consideration; I was making mistakes reading the I-D on the comfort of a
proper PC with good resolution etc (but with oldish eyes:-(















YL>> We can discuss this issue during the WG meeting in Montreal. I



don't have much preference on this.















Second, references need some work.  You identify the YANG modules as
version 1.1 but have an Informative Reference - must be Normative - to
YANG 1.0; confusing.  The Security Considerations are not the current
one;  e.g. you should reference RESTCONF and SSH. Might I suggest
looking at







draft-ietf-ccamp-mw-yang-06 ? And the section does reference RFC6241 and







RFC6536 which I cannot see in the Normative References















YL>> I think we have addressed theses references issues.















s.1    controller via a Netconf[RFC6020] interface.







No; NETCONF is not RFC6020















YL>> Corrected.















In the identity coding func you reference clauses 49, 82 and such like -
these need reference clauses to the relevant specification in the YANG
module.  This probably applies to most of these definitions (although
one comprehensive reference to any one document would suffice).















YL>> We put the MEF reference in the YANG module as well as in the



Reference Section from which all the terms and the original references
for specific clauses can be checked.















You need YANG reference clauses for







  import ietf-yang-types







and







  import ietf-l1-mef-service-types {















YL>> This was already done in Section 1.4. Let us know if this is what



you meant.















Likewise I recognise e.g. 'one way severely errored second' as a
technical term of the ITU-T; if that is what you intend, then these all
need a reference to the current ITU-T Recommendation.  If not, more
explanation is needed















YL>> It is indeed ITU-T term. The MEF document referenced has the



original ITU-T references.















You need YANG reference clauses for







  import ietf-yang-types







and







  import ietf-l1-mef-service-types {















YL>> I think this is the same comment as above.















Besides this,







- the running footing tells me that this is valid until 2028.















YL>> I am not sure which one you are pointing. If this is not fixed with



the revision, please let us know which one you are referring to.















-s 1.4 references [This I-D]







Suggest RFC XXXX (and add a note up front to the RFC Editor asking them
to replace XXXX with the number assigned to the RFC)















YL>> We corrected. See Section 1.4 for this.















-  grouping protocol-coding-optical_interface {







    description  "describes <p,c,o>";







p c o are not expanded in the YANG module - they need to be















YL>> We added description for each term.















-  grouping subscriber-l1vc-sls-service-attribute {







    description







      "The value of the Subscriber L1VC SLS (Service Level







        Specification) Service Attribute expressed in a 3-tuple







        of the form.";







leaves me asking what form does the 3-tuple take?















YL>> We added comment that the 3-tuple is <p,c,o>.















-      leaf time-interval {







        type int64;







        units seconds;







        description "a time interval (e.g., 1 month) ...







int64 is a lot of seconds and anyway cannot be used to express a month
since a month is a number of different lengths.  If a month is a
sensible time (seems long to me) then change it to 28 day and give the
value for 28 day in second and perhaps provide a default as that.  And
how about a range limiting this to something sensible (lest a typo sets
it to 2028 years)















YL>> We added an example with 28 days and changed int64 to int 16.















-      leaf subscriber-l1vc-ep-id-1 { type string;







        description "subscriber end point ID";  }















      leaf subscriber-l1vc-ep-id-2 { type string;







        description "subscriber end point ID"; Spot the difference - I
can't!















YL>> we added "subscriber end point ID for one end" and "subscriber end



point ID for the other end" to differentiate these two terms.







-  container l1cs







This is the sort of identifier I expect to be frequently misspelt!















YL>>  I would stick to this for now until we have discussion in the f2f



meeting.















Enough for now















Tom Petch















----- Original Message -----







From: "t.petch"

<ietfc@btconnect.com<mailto:ietfc@btconnect.com<mailto:ietfc@btconnect.c

om%3cmailto:ietfc@btconnect.com>>>







To: "Leeyoung"

<leeyoung@huawei.com<mailto:leeyoung@huawei.com<mailto:leeyoung@huawei.c

om%3cmailto:leeyoung@huawei.com>>>;



<ccamp@ietf.org<mailto:ccamp@ietf.org<mailto:ccamp@ietf.org%3cmailto:cca

mp@ietf.org<mailto:mp@ietf.org>>>>







Sent: Saturday, June 23, 2018 9:07 PM







Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt























> Young







>







> The most significant comment, for me, is the one about the







indentation;







> there came a point where I gave up trying to follow the I-D because it











> was so hard, so fix that and likely more comments will follow:-)







>







> Tom Petch







>







> ----- Original Message -----







> From: "Leeyoung"

<leeyoung@huawei.com<mailto:leeyoung@huawei.com<mailto:leeyoung@huawei.c

om%3cmailto:leeyoung@huawei.com>>>







> To:

<ccamp@ietf.org<mailto:ccamp@ietf.org<mailto:ccamp@ietf.org%3cmailto:cca

mp@ietf.org<mailto:mp@ietf.org>>>>







> Sent: Thursday, June 21, 2018 11:43 PM







>







> > Hi WG,







> >







> > This revision had some error in the date field in the yang model. So







> it is corrected; Tom's comments will be incorporated in the next







version







> (04).







> >







> > Thanks,







> > Young







> >







> > -----Original Message-----







> > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of







>

internet-drafts@ietf.org<mailto:internet-drafts@ietf.org<mailto:internet
<mailto:internet-drafts@ietf.org%3cmailto:internet-drafts@ietf.org%3cmai
lto:internet>

-drafts@ietf.org%3cmailto:internet-drafts@ietf.org<mailto:-drafts@ietf.o
rg%3cmailto:internet-drafts@ietf.org>>>







> > Sent: Thursday, June 21, 2018 5:35 PM







> > To:

i-d-announce@ietf.org<mailto:i-d-announce@ietf.org<mailto:i-d-announce@i
<mailto:i-d-announce@ietf.org%3cmailto:i-d-announce@ietf.org%3cmailto:i-
d-announce@i>

etf.org%3cmailto:i-d-announce@ietf.org>>







> > Cc:

ccamp@ietf.org<mailto:ccamp@ietf.org<mailto:ccamp@ietf.org%3cmailto:ccam
<mailto:ccamp@ietf.org%3cmailto:ccamp@ietf.org%3cmailto:ccamp@ietf.org%3
cmailto:ccam>

p@ietf.org<mailto:p@ietf.org>>>







> > Subject: [CCAMP] I-D Action: draft-ietf-ccamp-l1csm-yang-03.txt







> >







> >







> > A New Internet-Draft is available from the on-line Internet-Drafts







> directories.







> > This draft is a work item of the Common Control and Measurement







Plane







> WG of the IETF.







> >







> >         Title           : A Yang Data Model for L1 Connectivity







> Service Model (L1CSM)







> >         Authors         : G. Fioccola







> >                           K. Lee







> >                           Y. Lee







> >                           D. Dhody







> >                           D. Ceccarelli







> > Filename        : draft-ietf-ccamp-l1csm-yang-03.txt







> > Pages           : 24







> > Date            : 2018-06-21







> >







> > Abstract:







> >    This document provides a YANG data model for Layer 1 Connectivity







> >    Service Model (L1CSM).







> >







> >







> >







> >







> > The IETF datatracker status page for this draft is:







> > https://datatracker.ietf.org/doc/draft-ietf-ccamp-l1csm-yang/







> >







> > There are also htmlized versions available at:







> > https://tools.ietf.org/html/draft-ietf-ccamp-l1csm-yang-03







> > https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-l1csm-yang-03







> >







> > A diff from the previous version is available at:







> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-l1csm-yang-03







> >







> >







> > 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/







> >







> > _______________________________________________







> > CCAMP mailing list







> >

CCAMP@ietf.org<mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org%3cmailto:CCAM
<mailto:CCAMP@ietf.org%3cmailto:CCAMP@ietf.org%3cmailto:CCAMP@ietf.org%3
cmailto:CCAM>

P@ietf.org<mailto:P@ietf.org>>>







> > https://www.ietf.org/mailman/listinfo/ccamp







> >







> > _______________________________________________







> > CCAMP mailing list







> >

CCAMP@ietf.org<mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org%3cmailto:CCAM
<mailto:CCAMP@ietf.org%3cmailto:CCAMP@ietf.org%3cmailto:CCAMP@ietf.org%3
cmailto:CCAM>

P@ietf.org<mailto:P@ietf.org>>>







> > https://www.ietf.org/mailman/listinfo/ccamp







>







> _______________________________________________







> CCAMP mailing list







>

CCAMP@ietf.org<mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org%3cmailto:CCAM
<mailto:CCAMP@ietf.org%3cmailto:CCAMP@ietf.org%3cmailto:CCAMP@ietf.org%3
cmailto:CCAM>

P@ietf.org<mailto:P@ietf.org>>>







> https://www.ietf.org/mailman/listinfo/ccamp