Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment

Lyle Bertz <lyleb551144@gmail.com> Fri, 10 March 2017 17:41 UTC

Return-Path: <lyleb551144@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0715312706D for <netmod@ietfa.amsl.com>; Fri, 10 Mar 2017 09:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S3frFe1Uavr2 for <netmod@ietfa.amsl.com>; Fri, 10 Mar 2017 09:41:15 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3DA127077 for <netmod@ietf.org>; Fri, 10 Mar 2017 09:41:14 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id n11so652942wma.1 for <netmod@ietf.org>; Fri, 10 Mar 2017 09:41:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5werkdan7lNzTWRRBeDH89QFXGxb4hwCHDtQ8Gko90w=; b=PFEL2Ea0rF7TTVYlyU9dnPIBnSjYEHcKvIN9APmiRkjHdBacrC4012NM/Um3BHN6y4 Qz1xEbxeu5ekVZ2BKL1o3KwZ81lrqmAIwYS3TUENqTkt+sgote+JDoTiXVusuUZOokQn dFzfoJXgBYZEQbZ7NlX8kSs0UINqCC4qSdzlPLL3PQFz+n69V4QPNOsf/K8a5YSG1OG2 3dCjmHWTSuHoqBXwXlOiFLb8e/FarToiBEtHz0FcstE9LOc6NAux4aM+HBJ7xR9TDFXE MLQuTUqirsAeSjvpQSPoDO1L9PE0cat/ixnn6gP0JMaeFF1bYjxHljx4mwW2SGTzVChu fl7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5werkdan7lNzTWRRBeDH89QFXGxb4hwCHDtQ8Gko90w=; b=J1nOwEyc8c+gGBaPsIWgM7kA53DtOkm6RDAwpt+CkWaQ1UbaAgGTRqAhr+B5pXERgT 7hLs8Kq83eFVX9keUh5v1SmGkva2JQ6lBKa28MwEaR4A9puVnVGhCFk+69j9UGYGv4Mu 8MzxBuG7gdAD84THsVM5jJaTNz2ni01jyUAp5SeZ50BckZnem6r5VWC2SxnPTw48sN1G ypzYwqg6n5UF4FhOmmI6ZGiJu9dEbsw1akLVC2DFdFpLjao5XsE61GR5vshc/4IEPmuR /RJmpiAUOtKEqsRWf2iKS04zPzQugFndRb985X0znrJcHVndwduZ5u6CzsKHcSflwoOF 6AzQ==
X-Gm-Message-State: AFeK/H2h+Bg/PQnslPdjWyM2y9egAWbN4xGYI31nzPwSSYm1IIB7QBA+0TyaHPy1COUw8F3vz/Ibdg9mKpT0Jg==
X-Received: by 10.28.191.24 with SMTP id p24mr132300wmf.118.1489167673049; Fri, 10 Mar 2017 09:41:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.27.86 with HTTP; Fri, 10 Mar 2017 09:41:12 -0800 (PST)
In-Reply-To: <m21su5z04u.fsf@birdie.labs.nic.cz>
References: <CAC5bAia030UoPbtqa6vu7u745XTm2JLvncFmkXQrHQApaUs4Ow@mail.gmail.com> <m2innlcw8l.fsf@nic.cz> <CAC5bAiY06j52yU-B_x_jHyxkNTOPCKdv8nkkoHbazKsXiniHCg@mail.gmail.com> <m21su5z04u.fsf@birdie.labs.nic.cz>
From: Lyle Bertz <lyleb551144@gmail.com>
Date: Fri, 10 Mar 2017 11:41:12 -0600
Message-ID: <CAC5bAiZnaENb=-YRzejsTad20nQdG0p9Uf0eWUxJaZfcEVOg4Q@mail.gmail.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a114d53ae29c903054a63dec0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MTmN_5F7QSdtKBHoNw6YiYHkdo0>
Cc: netmod@ietf.org
Subject: Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2017 17:41:17 -0000

We did that.  Unfortunately, underlying YANG to object oriented code
generators treated the wrapping class as only inheriting the interface.
This seems fine until you attempt to translate from one of these classes to
another and the real work is much larger than expected.  Part of this is
the schema context carried in one object to another - copying is not just
copying as we began to discover.

The proposal's end result is the same as you propose - a grouping with
multiple augments and this is sufficient from a standards level as it
achieves the correct structures.  However, it appears to as separate,
independent modifications to the schema tree.   Thus, the intent of the
author (for it to be the same augment / addition in multiple locations) is
lost.

We then thought, "okay, modify the compiler to just assume equivalence"
which only works a) if that is true and b) if the signature is exactly the
same.  We could not guarantee a) and b) become problematic when computing
"exactly the same"; especially across modules (which is another subject
entirely).

The final issue is one of space.  If you only support the extension you
have the intent of the author and a smaller amount of YANG.  However, we
keep the proposal backwards compatible assuming that we will not just dump
old YANG files for slightly better ones.

A final point, this should not be an issue in the main information tree as
it implies you have an object "everywhere" which begs several questions
regarding design.  It is however a common problem when you have several
rpcs that send data in the request and response.  It was in the rpc
definitions that we really took a hit when implementing the DMM FPC drafts.

Lyle


On Fri, Mar 10, 2017 at 8:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Lyle Bertz <lyleb551144@gmail.com> writes:
>
> > Understood.
> >
> > Let's discuss at the meeting though.  This was a significant issue in the
> > development of the IETF DMM FPC yang files and our open source project.
>  I
> > am open to this going in the proper direction wherever that is but wanted
> > to bring the issue and a possible solution to the table.
>
> Yes, that's fine. One way to alleviate this problem is to define a
> grouping and then have multiple augments that use this grouping. We used
> this approach in RFC 8022. Would this work for your use cases?
>
> Lada
>
> >
> > Lyle
> >
> >
> > On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >> Hi,
> >>
> >> while the use case is clear, I believe such rather fundamental changes
> >> to YANG cannot be done through extensions because otherwise the value of
> >> YANG as a standard will be lost.
> >>
> >> Lada
> >>
> >> Lyle Bertz <lyleb551144@gmail.com> writes:
> >>
> >> > All,
> >> >
> >> > This is a small submission that allows a single augment statement to
> be
> >> > used to augment multiple schema locations or, at the very least, give
> the
> >> > YANG to language generation tools a hint that the augment is similar
> to
> >> > other augments in the module.
> >> >
> >> > It can be found at
> >> > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/
> >> >
> >> > It is in direct response to issues that arose writing YANG for the
> IETF
> >> DMM
> >> > FPC specification that can be found at
> >> > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/
> >> >
> >> > and also in response to issues found wrt yangtools (OpenDaylight) code
> >> > generation of the FPC specification.
> >> >
> >> > Lyle
> >> > _______________________________________________
> >> > netmod mailing list
> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>