Hi Giuseppe, please see inline. On Wed, 2018-02-28 at 13:15 +0000, Fioccola Giuseppe wrote: > Hi Ladislav, > Thank you! We are working on a new revision that incorporates your comments. > My answers inline tagged as [GF]. > > Best Regards, > > Giuseppe > > -----Messaggio originale----- > Da: Ladislav Lhotka [mailto:lhotka@xxxxxx] > Inviato: lunedì 26 febbraio 2018 13:35 > A: yang-doctors@xxxxxxxx > Cc: l2sm@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-l2sm-l2vpn-service-model.all@ietf > .org > Oggetto: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 > > Reviewer: Ladislav Lhotka > Review result: Ready with Issues > > **** General comments > > - The 'ietf-l2vpn-svc' module contained in this document is > rather large: it defines 386 schema nodes, 35 features and 175 > identities. It is therefore natural to ask whether the authors > considered splitting the definitions into multiple > modules. This would make the data model more modular and > probably also make some of the features unnecessary. See also > draft-ietf-netmod-rfc6087bis-18, sec. 4.17. > > [GF]: Ok, Thanks for the suggestion. We will remove unnecessary identities, > features. Note that unlike network element model, service model will describe > various aspects of network infrastructure, including devices and their > subsystems, and relevant protocols operating at the link and network layers > across multiple device. So it is intentional to have such model design. Yes, but RFC 8199 also talks about monolithic versus component-based approaches in relation to network service models. I am not saying that your design is wrong, just suggesting to consider the alternatives that could possibly make this relatively big data model easier to comprehend. > > - The module defines most containers, lists and even individual > leaves in a grouping that is then used only once. This approach > has its pros nad cons but it is not the common practice in YANG > modelling - groupings are mostly defined only if they are used (or > expected to be used) repeatedly and/or in different modules. > > [GF]: It is expected some of these groupings can be reused in some other > external modules, or model extension. If only some of them are intended to be reused, then I would suggest to remove those that aren't. Model extensions are usually implemented with an augment, and groupings don't help in this case. Thanks, Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
