Hi Ladislav, My answers inline tagged as [GF]. Best regards, Giuseppe -----Messaggio originale----- Da: Ladislav Lhotka [mailto:lhotka@xxxxxx] Inviato: mercoledì 28 febbraio 2018 15:58 A: Fioccola Giuseppe; yang-doctors@xxxxxxxx Cc: l2sm@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-l2sm-l2vpn-service-model.all@xxxxxxxx Oggetto: Re: R: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 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. [GF]: We would prefer to keep L2SM aligned with RFC 8299 (L3SM) by using a similar approach and we will try to simplify as much as we can as it is suggested by RFC 8199. > > - 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. [GF]: Understand. Will check and remove those that are not reused. Thanks, Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non è necessario.
