Re: [L2sm] R: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08

[Ladislav Lhotka <[e-mail]>]

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:[e-mail]] 
> Inviato: lunedì 26 febbraio 2018 13:35
> A: [e-mail]
> Cc: [e-mail]; [e-mail]; 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