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

Ladislav Lhotka <> Wed, 28 February 2018 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E03C12EAF9; Wed, 28 Feb 2018 06:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PTGxz_sbEzvN; Wed, 28 Feb 2018 06:58:06 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8481312DA4C; Wed, 28 Feb 2018 06:58:05 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3038:3cff:fe84:3622]) by (Postfix) with ESMTPSA id 3268162430; Wed, 28 Feb 2018 15:58:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1519829883; bh=TG2WB/CPxdHuS2IJLcENyHbHZWizw8+edchPu3wFmIE=; h=From:To:Date; b=SDtDYM02yo2dvVKj32z9Rb+ezHcyjSSYSrtsYX1zen/dQcR+b6wp1nAfxeVSoIlhn JSOqn2OfMmh41PSxyptaMZMu5dfy/Z+GZ5onOS4ETIEIEI4JSpe2YtlgoT/hE1L/pb jCXOZs2tKhAJlEJmzuH/XvY+aF28z146BrOZjkgs=
Message-ID: <>
From: Ladislav Lhotka <>
To: Fioccola Giuseppe <>, "" <>
Cc: "" <>, "" <>, "" <>
Date: Wed, 28 Feb 2018 15:58:03 +0100
In-Reply-To: <a29f08b341cd472597badb2e6e55463f@TELMBXB02RM001.telecomitalia.local>
References: <> <a29f08b341cd472597badb2e6e55463f@TELMBXB02RM001.telecomitalia.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [L2sm] R: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Feb 2018 14:58:09 -0000

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