Re: [Softwires] Yangdoctors last call review of draft-ietf-softwire-yang-06
tom petch <daedulus@btconnect.com> Wed, 24 October 2018 15:58 UTC
Return-Path: <daedulus@btconnect.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E6D130EEA; Wed, 24 Oct 2018 08:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 7RVj9xUd7ZKx; Wed, 24 Oct 2018 08:58:00 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC57130EEE; Wed, 24 Oct 2018 08:57:50 -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=Iwhf4RoxkL3Om+lowTDkDCJh948j2ViyIik0f+Y8HB8=; b=N1Mc/sFHMvddHeK8BvazaY+ahyUfkF5tuWubUgrKz3ofq/XjrEIXrCVs7mOwOfEkTYiXx9DqNSi3qtC4FdlYG5NiCDUgjz8wWCB1z6HKLrDP91CavN3j6Nbeunu10wJExnIZIvCDqKTgQX9NOaKic3aoWptVSyUsnqxhzpUdYkY=
Received: from AM5PR0701MB2337.eurprd07.prod.outlook.com (10.169.152.135) by AM5PR0701MB2931.eurprd07.prod.outlook.com (10.168.156.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.13; Wed, 24 Oct 2018 15:57:47 +0000
Received: from AM5PR0701MB2337.eurprd07.prod.outlook.com ([fe80::79e8:2286:973f:44e1]) by AM5PR0701MB2337.eurprd07.prod.outlook.com ([fe80::79e8:2286:973f:44e1%8]) with mapi id 15.20.1273.019; Wed, 24 Oct 2018 15:57:47 +0000
From: tom petch <daedulus@btconnect.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "softwires@ietf.org" <softwires@ietf.org>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-softwire-yang.all@ietf.org" <draft-ietf-softwire-yang.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Yangdoctors last call review of draft-ietf-softwire-yang-06
Thread-Index: AQHUa7JOvRPHkhQBLU+ebWFJIgGpUw==
Date: Wed, 24 Oct 2018 15:57:46 +0000
Message-ID: <01a501d46bb2$24fd0760$4001a8c0@gateway.2wire.net>
References: <787AE7BB302AE849A7480A190F8B93302E019B52@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20181023.153003.558721163541938191.mbj@tail-f.com> <787AE7BB302AE849A7480A190F8B93302E019F79@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20181024.083145.456303270328710769.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: CWXP265CA0005.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2e::17) To AM5PR0701MB2337.eurprd07.prod.outlook.com (2603:10a6:203:e::7)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.131.229.47]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2931; 6:kaWLxvk2klazgUSII3Es//g8G7rWMmLTTsAOWr159kMRgWC2oVWNkS/6Fl2tqnCW20NMaHe9gvXo9ArfTiBZJD61AQ753c+DubrKNe1/fXJE0jrAkLmVHVYa2E1Dlb90kk/fJVeslw/F9I2WzkrzV7EmDK7KVctk0F9hxY2UrkwXevYexr9SnavdVTOzmWijiL7HIDwmJS5IFPAGzITVpGkxBk+ykWlR5gIpLW/MfWpAmtuMue/z4NZGmZqk9ztnAzr+lEWxHo60nSrihk4JyCYLvPI8ZkwftC6dmTDFNX3HcNSFvWMXoNLKko3smRgNfDpkRcTtwnwiV1XvmsRtX06b+lLEunQZ8qqdv7n9R44h3LS33bfvKpeC4ObiQvlQVHrwVStEBNWb3qsSdYUVMOgzYuZGPgQ3+Cjr60mcTP/kzt0Nh8HQHERKS3pIWt0HWV6xUVcggP11wB+kv4ud8w==; 5:zG4yXhV923pzr6DvbCNfk43hwOP4WktMDP8pPwo9Zbj9zjy81/YamLTVoCE+X8Tf80C/BWfHGiKPOJxb8Xe5q9Sk+GFcVROmUntYyWrHhHk3jpElZw5ivDH5DG7p+ybqj/14+eNNEuaob+pvwLBAdRWxC4hxaBvESaodaCCCqrI=; 7:kdJr4u+Rv7v9iqNj4OO1SU2XxgkT1kauRV14dmJPSuj5ouTSPw85GwVcwEne+QjwXSckOXK68KvGH2MSnVYMSwmzBIgRQ6b/6v9exu1mNrkPmh+sj3RqLQTlVY++7rIN1+oCF/sAD51YZmZ5hitUoQ==
x-ms-office365-filtering-correlation-id: 3b3b2d3d-8d82-4f44-34b7-08d639c970f1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:AM5PR0701MB2931;
x-ms-traffictypediagnostic: AM5PR0701MB2931:
x-microsoft-antispam-prvs: <AM5PR0701MB2931B1AB7E3652D4F0561A10C6F60@AM5PR0701MB2931.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(1591387915157)(158342451672863)(18271650672692)(161740460382875);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM5PR0701MB2931; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2931;
x-forefront-prvs: 083526BF8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(366004)(346002)(39860400002)(189003)(199004)(51444003)(52314003)(13464003)(55784004)(51914003)(6506007)(229853002)(52116002)(2900100001)(102836004)(6246003)(8676002)(14454004)(76176011)(25786009)(33896004)(7736002)(44736005)(6486002)(8936002)(97736004)(84392002)(86152003)(2906002)(9686003)(6512007)(6306002)(99286004)(966005)(3846002)(6116002)(53946003)(53936002)(6436002)(305945005)(5660300001)(386003)(71190400001)(486006)(1556002)(256004)(105586002)(71200400001)(476003)(446003)(93886005)(14444005)(4744004)(2501003)(81156014)(81166006)(66066001)(26005)(186003)(86362001)(66574009)(68736007)(106356001)(14496001)(316002)(345774005)(5250100002)(110136005)(54906003)(478600001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2931; H:AM5PR0701MB2337.eurprd07.prod.outlook.com; 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-antispam-message-info: EKFiq0B2+/nrKe1tCeEomxlGzwrSquwvjJyaSGUjwP08EsdPXlgUvS0ayD4gwfoEGBngAhAykG/NPdGUPlGdTxtRsn4JHQNKKaqbWsPoVHh9L8rqMJZfW0l+NIJpOPAwq/APj+Jr8saAoeDra0/Q6iTrnAeJN5H59HdbfMbfzuuatOl1aktBgeupLGQJ8w1PS2cbW+hQha8jJhXTEj1zqM9MzX6wSNk2rqRIEFpVON8gJpFUfi/4UwUIT5lTdsQ/Hm32qbLViMfvU0n8HZlRp+RKTFvTBXa1/BiQ10JcXBnXJVRcLbNRR7HSDFMBHHSYUMMM9whiJzVF9AKXOUSsqMshPckt9I5+oiDvjgBpqVA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B2B7612C1C30C34183E0A95FBECCB8E6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b3b2d3d-8d82-4f44-34b7-08d639c970f1
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 15:57:47.0073 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2931
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/FxxiaiN0TZGKWnyyDqFu-Wyca5E>
Subject: Re: [Softwires] Yangdoctors last call review of draft-ietf-softwire-yang-06
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 15:58:05 -0000
Martin I am still catching up with all the changes, and it is that time - IETF meeting time - when the world seems to spin a little faster yielding four revisions in a day! One query for you; are you ok with the map-e and map-t features being defined separately in each module? I had thought to put them in the common module and then import them, using a prefix. I had also thought to have a map feature from which map-e and map-t were derived but that seems unnecessarily complicated. Tom Petch ----- Original Message ----- From: "Martin Bjorklund" <mbj@tail-f.com> To: <mohamed.boucadair@orange.com> Cc: <softwires@ietf.org>; <yang-doctors@ietf.org>; <draft-ietf-softwire-yang.all@ietf.org>; <ietf@ietf.org> Sent: Wednesday, October 24, 2018 7:31 AM Subject: Re: Yangdoctors last call review of draft-ietf-softwire-yang-06 Hi, <mohamed.boucadair@orange.com> wrote: > Re-, > > Fixed the first two ones in my local copy. > > id is optional. I'm maintaining it because it is already used by some > implementations. Ok, but these implementations propably need to change anyway since the "id" is no longer the key. I will just point out that having one key and another integer based identifier that doesn't serve any purpose looks a bit odd. But if the WG thinks that it is needed then that's fine (although in this case I suggest you add some text to the descriptions of these leafs that explain what the purpose is). I had a closer look at the iana-tunnel-type module and the instructions to IANA, and I think that you could make some minor clarificiations: In the module description, you have: This module contains a collection of YANG data types defined by IANA and used for tunnel types. perhaps write: This module contains a collection of YANG identities defined by IANA and used as interface types for tunnel interfaces. And in the IANA Considerations section you have: "base": Contains the value of the tunnel type in lowercase. maybe instead "base": Contains the string "ift:tunnel". /martin > > Thank you again for the review. Much appreciated! > > Cheers, > Med > > > -----Message d'origine----- > > De : Martin Bjorklund [mailto:mbj@tail-f.com] > > Envoyé : mardi 23 octobre 2018 15:30 > > À : BOUCADAIR Mohamed TGI/OLN > > Cc : yang-doctors@ietf.org; softwires@ietf.org; draft-ietf-softwire- > > yang.all@ietf.org; ietf@ietf.org > > Objet : Re: Yangdoctors last call review of > > draft-ietf-softwire-yang-06 > > > > Hi, > > > > Thanks for the quick update! > > > > I have looked at -11, and have just a few minor comments. > > > > o Section 5.1 > > > > Maybe the tree diagram needs to be re-generated; at least: > > > > | +--rw bind-instance* [id] > > > > should be > > > > | +--rw bind-instance* [name] > > > > > > > > o Section 8 > > > > > > leaf softwire-num-max { > > type uint32; > > must ". >= 1"; > > > > This should be: > > > > leaf softwire-num-max { > > type uint32 { > > range "1..max"; > > } > > > > > > o Section 8 > > > > Since you now have "name" as key in the lists, is the leaf "id" > > still needed? > > > > > > > > > > /martin > > > > > > > > <mohamed.boucadair@orange.com> wrote: > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Envoyé : mardi 23 octobre 2018 10:05 > > > > À : BOUCADAIR Mohamed TGI/OLN > > > > Cc : yang-doctors@ietf.org; softwires@ietf.org; draft-ietf-softwire- > > > > yang.all@ietf.org; ietf@ietf.org > > > > Objet : Re: Yangdoctors last call review of > > > > draft-ietf-softwire-yang-06 > > > > > > > > Hi, > > > > > > > > <mohamed.boucadair@orange.com> wrote: > > > > > Hi Martin, > > > > > > > > > > Thank you for the review. > > > > > > > > > > We released a new revision -08 to address your comments. We will > > > > > double check the formatting and issue another iteration if needed. > > > > > > > > Thank's for addressing my comments. See inline and at the end for > > > > some new comments on -08. > > > > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Martin Björklund [mailto:mbj@tail-f.com] > > > > > > Envoyé : lundi 15 octobre 2018 11:00 > > > > > > À : yang-doctors@ietf.org > > > > > > Cc : softwires@ietf.org; draft-ietf-softwire-yang.all@ietf.org; > > > > ietf@ietf.org > > > > > > Objet : Yangdoctors last call review of draft-ietf-softwire-yang-06 > > > > > > > > > > > > Reviewer: Martin Björklund > > > > > > Review result: Ready with Issues > > > > > > > > > > > > This is my YANG doctor review of draft-ietf-softwire-yang-06. The > > > > > > review focuses on YANG-specifics only, since I am not familiar with > > > > > > the technology that is modelled. > > > > > > > > > > > > o I would like to see all Tom Petch's comments in his three replies > > > > > > to the IETF LC for this document addressed. Especially his > > comment > > > > > > about using ianatf:tunnel. > > > > > > > > > > > > > > > > [Med] This is fixed in -07. A new tunnel-type parameter is defined > > > > > to handle this. > > > > > > > > I think that the addition of identities for various tunnel types that > > > > derive from ift:tunnel is the right thing to do. > > > > > > [Med] OK, thanks > > > > > > > > > > > However, since these identities derive from ift:tunnel, the > > > > augmentation of ietf-interfaces in ietf-interface-tunnel is not > > > > needed. > > > > > > [Med] ietf-interface-tunnel tries to preserve a similar structure as > > > in > > https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, but > > you are > > right we can get rid of it. > > > > > > Instead, the new identities should be used as if:type > > > > directly. For example, instead of: > > > > > > > > <interface xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> > > > > <name>lw4o6-wan</name> > > > > <type>ianaift:tunnel</type> > > > > <tunnel-type > > > > xmlns:iana-tunnel-type="urn:ietf:params:xml:ns:yang:iana-tunnel- > > type"> > > > > iana-tunnel-type:aplusp > > > > </tunnel-type> > > > > ... > > > > </interface> > > > > > > > > you should do: > > > > > > > > <interface> > > > > xmlns:iana-tunnel-type="urn:ietf:params:xml:ns:yang:iana-tunnel- > > type"> > > > > <name>lw4o6-wan</name> > > > > <type>iana-tunnel-type:aplusp</type> > > > > ... > > > > </interface> > > > > > > > > So, I think you should remove the ietf-tunnel-type module. > > > > > > > > > > [Med] OK. > > > > > > > > > > > An additional comment on the identities in iana-tunnel-type; for each > > > > identity, I think you should add a "reference" statement that points > > > > to the RFC(s) that define the tunnel. (available in the IANA registry > > > > at > > > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- > > numbers-5) > > > > > > > > > > [Med] I guess you meant > > > https://www.iana.org/assignments/smi-numbers/smi- > > numbers.xhtml#smi-numbers-6. Fixed in my local copy, except form > > IPHTTPS for > > which we don't have an RFC. > > > > > > > > > > > > > > > > > o The term "instance" is used to mean - I think - the "device". > > > > > > > > > > [Med] It is used to mean function rather than device. A device may > > > > > enable multiple instances of the same function. > > > > > > > > But you have for example in the description of "binding-mode": > > > > > > > > This feature indicates that the instance functions as a binding > > > > based softwire instance. > > > > > > > > And in container algo-instances you have: > > > > > > > > The instances advertise the MAP-E/MAP-T > > > > feature through the capability exchange mechanism > > > > when a NETCONF session is established." > > > > > > > > Unless your intentation is that one "instance" == one "function" == > > > > one NETCONF server, then this text is not correct. > > > > > > > > So I am a bit confused - if the device advertises the feature > > > > "binding-mode" it means that "it functions as a binding based softwire > > > > instance". Maybe you mean something along the lines of > > > > > > > > This feature indicates that the network element can function as > > > > one or more binding based softwire instances. > > > > > > > > > > [Med] This is it. Updates when appropriate. > > > > > > > (I don't know if you want to use the term "network element" or > > > > something else.) > > > > > > > > > > [Med] Network element is fine. > > > > > > > > > > > Also there is similar text for the features map-e and map-t. > > > > > > > > > > > > > > [Med] Yes. > > > > > > > Anyway, if this meaning of the word "instance" is defined somewhere, > > > > I suggest you add a reference to that other doc; or else explain this > > > > meaning in 1.1. > > > > > > > > > > [Med] added to the terminology section: > > > > > > A network element may support one or multiple instances of a softwire > > > mechanism; each of these instances may have its own configuration and > > > parameters. > > > > > > > > > > > > I > > > > > > didn't find this term in the RFCs 7596, 7597 or 7599. I suggest > > > > > > you use some other term, since "instance" is quite generic, and is > > > > > > often used to refer to instances of YANG data nodes. > > > > > > > > > > > > Also, does the term "instance" mean the same thing in > > > > > > "algo-instance"? And in "br-instances"? "bind-instance"? > > > > > > > > > > > > > > > > > [Med] algo-instance means an instance of type > > > > > algorithm. br-instances denotes a set of br instances, and > > > > > bind-instance means an instance of type binding. > > > > > > > > I could guess that. I think the issue is when the word "instance" is > > > > used unqualified. > > > > > > [Med] Updated to avoid unqualified "instances" > > > > > > > > > > > > > o In ietf-softwire-common: > > > > > > > > > > > > grouping algorithm-instance { > > > > > > description > > > > > > "Indicates that the instance supports the MAP-E and MAP-T > > > > > > function. The instance advertises the MAP-E/MAP-T feature > > > > > > through the capability exchange mechanism when a NETCONF > > > > > > session is established."; > > > > > > > > > > > > This description does not seem right. A grouping can't indicate > > > > > > anything. Also, what is "the MAP-E/MAP-T feature"? > > > > > > > > > > > > > > > > [Med] Fixed. > > > > > > > > > > > > > > > > > o In ietf-softwire-ce: > > > > > > > > > > > > A similar description is found here: > > > > > > > > > > > > container algo-instances { > > > > > > description > > > > > > "Indicates that the instances supports the MAP-E and MAP- > > T > > > > > > function. The instances advertise the MAP-E/MAP-T > > > > > > feature through the capability exchange mechanism > > > > > > when a NETCONF session is established."; > > > > > > > > > > > > same comments apply. > > > > > > > > > > > > > > > > [Med] Fixed. > > > > > > > > This text is still present, with a minor change: > > > > > > > > container algo-instances { > > > > description > > > > "Indicates that the instances supports the MAP-E and/or MAP-T > > > > function. The instances advertise the MAP-E/MAP-T > > > > feature through the capability exchange mechanism > > > > when a NETCONF session is established."; > > > > > > > > But since the container "algo-instances" is a non-presence container, > > > > it can't "indicate" anything. This text needs to be rephrased. > > > > > > > > > > [Med] Updated accordingly. > > > > > > > > > > > > > o In ietf-softwire-common: > > > > > > > > > > > > container algo-versioning { > > > > > > description "algorithm's version"; > > > > > > leaf version { > > > > > > type uint64; > > > > > > description "Incremental version number for the algorithm"; > > > > > > } > > > > > > leaf date { > > > > > > type yang:date-and-time; > > > > > > description "Timestamp to the algorithm"; > > > > > > } > > > > > > } > > > > > > > > > > > > Maybe these descriptions are crystal clear to someone who knows the > > > > > > technology. If so, perhaps add a reference to help the rest of us? > > > > > > > > > > > > > > > > [Med] This is used for logging purposes. A reference to RFC7422 is > > added. > > > > > > > > Ok. I still don't really understand how it is supposed to be used. > > > > > > > > When you write "version number for the algorithm", do you mean > > > > "version number for this algo-instance"? > > > > > > [Med] What is meant is: > > > > > > "Incremental version number for the mapping > > > algorithm rules provided to the algorithm instance"; > > > > > > An algorithm instance may be provided with mapping rules that may > > > change in > > time (for example, increase the size of the port set). When an abuse > > party > > presents an external IP address/port, the version of the algorithm is > > important because depending on the version, a distinct customer may be > > identified. The timestamp is used as a key to find the appropriate > > algorithm > > that was put into effect when an abuse occurred. > > > > > > Updated the description among these lines. > > > > > > > > > > > These are config true leafs; should they be config false and > > > > internally managed by the server? > > > > > > [Med] This can be generated by the server or set by an operator. > > > > > > If not, I suppose an operator can > > > > set them to any suitable values? If so, what does "incremental > > > > version number" really mean? Is the server supposed to reject a value > > > > that is not "incremental"? > > > > > > [Med] What is important is to have a unique version number, how is set > > > is > > not important. Incremental seems to be straightforward, but one may > > envisage > > other ways to manage versions. I deleted "incremental". > > > > > > > > > > > [...] > > > > > > > > > > Also, it seems each "instance" has a numerical id (the key), but > > > > > > also a name (a string). Maybe there are protocol-reasons to do > > > > > > this, but if not, did you consider using the "name" as key instead? > > > > > > > > > > > > > > > > [Med] id/name is inspired from how NAT instances are managed (see > > > > > RFC7659). The name is optional. > > > > > > > > Well, in MIBs instances are normally identified with integers b/c of > > > > how the protocol (SNMP) works. In YANG modules, we usually use a > > > > "name" that is a string to identify instances. With a string, the > > > > operator can choose meaningful names, and use them in other leafrefs, > > > > instead of having to remember how the names are mapped to integers. > > > > > > > > (Compare ifIndex (MIB) w/ interface/name (YANG)) > > > > > > > > So I suggest you use "name" as key. > > > > > > [Med] If you think this is better, I'm fine with that. > > > > > > > > > > > > > > > > > > > o I also note that you have changed the name of some lists in -08, > > > > e.g., list "bind-instance" is now list "bind-instances" > > > > (plural). Another example is: > > > > > > > > +--rw algo-instances > > > > +--rw algo-instances* [id] > > > > > > > > I think you should change these back to singluar; that's what YANG > > > > modules typically use. > > > > > > > > > > > > > > [Med] Actually, this was a comment from Tom. Perhaps, we misunderstood > > > it. > > OK to change it back if this is the recommended practice. > > > > > > > > > > > > > > > /martin > > > >
- [Softwires] Yangdoctors last call review of draft… Martin Björklund
- Re: [Softwires] Yangdoctors last call review of d… mohamed.boucadair
- Re: [Softwires] Yangdoctors last call review of d… Martin Bjorklund
- Re: [Softwires] Yangdoctors last call review of d… mohamed.boucadair
- Re: [Softwires] Yangdoctors last call review of d… Martin Bjorklund
- Re: [Softwires] Yangdoctors last call review of d… mohamed.boucadair
- Re: [Softwires] Yangdoctors last call review of d… Martin Bjorklund
- Re: [Softwires] Yangdoctors last call review of d… mohamed.boucadair
- Re: [Softwires] Yangdoctors last call review of d… tom petch
- Re: [Softwires] Yangdoctors last call review of d… mohamed.boucadair