Re: [netmod] new YANG 1.1 Issue Y61: I2RS support

Andy Bierman <andy@yumaworks.com> Thu, 30 July 2015 18:30 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C797F1B2C5B for <netmod@ietfa.amsl.com>; Thu, 30 Jul 2015 11:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 ND9l4mVvvcRm for <netmod@ietfa.amsl.com>; Thu, 30 Jul 2015 11:30:28 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 DCE691ACD2F for <netmod@ietf.org>; Thu, 30 Jul 2015 11:30:27 -0700 (PDT)
Received: by lbqc9 with SMTP id c9so7224449lbq.1 for <netmod@ietf.org>; Thu, 30 Jul 2015 11:30:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WArNMCSYJLL5Z+sgIaX/UyhPJ0A6G8b4awDu17yG4qM=; b=PR4izuHheEWtzxS2pgrWxBX75p0pl4r+McP8Sa/LvaJtTCf5oMePY5prmbmZGGrrIk tTMl0ZJVO0vfMtv24bMNDaF7rmi5uBFgULo7MFFKUYre8iPaBe1NWZ6oDb9SbVwQ2k3u wvadg3KB+L4KwxNI36cKSX2x7n3/zFVgW1PYcGutR24Uk77IJR7xqgGHEQgvnTdp+eHM +kBt0HgS8915WjplTp+MzEuL5Bd8ATs4fE1aJxIucKbOPenupZM0RaqrpSdwH3Jqedry WVUtGWYorUSPO/maanfu2vV+M+NLah65GGYBzqWHKfj6XRpJw69Z+DZzNRjjtCbSrneR ipeQ==
X-Gm-Message-State: ALoCoQmfM8jMgDgit4LEd+ya4WE6V1bzcpUS1IFQptC4y60/LV2atYK7EdfudQe6WlpJR6lZzMsV
MIME-Version: 1.0
X-Received: by 10.152.36.161 with SMTP id r1mr45345811laj.88.1438281026397; Thu, 30 Jul 2015 11:30:26 -0700 (PDT)
Received: by 10.112.200.102 with HTTP; Thu, 30 Jul 2015 11:30:26 -0700 (PDT)
In-Reply-To: <20150730.201912.763525508503943000.mbj@tail-f.com>
References: <CABCOCHSPZQMJ2dt1AWLWdx0zfukn+qJ3RUzd_P5X=-BEYyyTfw@mail.gmail.com> <20150730.194130.1378875555824248389.mbj@tail-f.com> <CABCOCHQrZqxKM6cBzij6hWzMUa8DbKSAULr5gW3fhBBV_OZjRw@mail.gmail.com> <20150730.201912.763525508503943000.mbj@tail-f.com>
Date: Thu, 30 Jul 2015 11:30:26 -0700
Message-ID: <CABCOCHQ+5Lo618_nW+6zvg+vGv1k2CqY9ahUsmBbv0Xt+Mo2SQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="089e0158b5e4aa7ddb051c1be54e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/464D_fygJ6o8bFyKVcL-kEA8M78>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 30 Jul 2015 18:30:31 -0000

Hi,

I don't think I2RS is slowing down YANG 1.1.
The ephemeral state issue has been known to the NETMOD WG
for over a year.  I don't care if YANG 1.1 is delayed a month because
the solution details need to be worked out.

An ephemeral datastore would be useful for describing the collection of
YANG data nodes that share the ephemeral property.
A YANG statement is needed so ephemeral only data can
have its own validation rules.  I strongly object to using
extensions because they are not part of YANG.  They
cannot be used properly in refine-stmt or deviate-stmt.
They can be ignored by YANG tools.
Extensions are fine for proprietary usage, but not standards.





On Thu, Jul 30, 2015 at 11:19 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.com> wrote:
> > On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> >
> > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <mbj@tail-f.com>
> > > wrote:
> > > >
> > > > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I understand the intent is that an implementation of NACM
> > > > > > has to understand these NACM extensions.  I agree with Lada
> > > > > > that the YANG text about MAY ignore extensions casts doubt
> whether
> > > > > > this sort of NACM rule is enforceable or specified correctly.
> > > > >
> > > > > So do you agree that it would be a good idea to clarify this
> > > > > according to Juergen's suggestion?
> > > > >
> > > > >
> > > > >
> > > > Not really.
> > > > Pretending the extension is just another description-stmt
> > > > does not really fix anything.
> > > >
> > > > A real YANG statement like config-stmt or a new statement
> > > > called ephemeral-stmt can be modified with refine-stmt
> > > > or deviate-stmt.   This can never happen for
> > > > an external statement.
> > >
> > > There are two separate issues here:
> > >
> > > 1) It seems we are in agreement that if a model uses an extension
> > >    statement, it is normative (like ietf-system's usage of nacm:*).
> > >
> > >    Should we somehow clarify this in 6020bis?
> > >
> > >
> > No -- I agree that was the intent, but it is not achievable
> > because tools MAY ignore extensions.
>
> But as have been said several times, this was clearly not the
> intention.  So we should clarify this in 6020bis.
>
> > > 2) Extensions cannot be refined or deviated.
> > >
> > >    Actually, the *syntax* rules allows things like:
> > >
> > >      deviation /x:foo {
> > >        deviate replace {
> > >          i2rs:ephemeral true;
> > >        }
> > >      }
> > >
> > >    I agree that it not clear what this means, but we could also
> > >    clarify this in 6020bis.
> > >
> > >
> > > > IMO ephemeral data support needs to be a real statement
> > > > that can be used with refine-stmt and  deviate-stmt.
> > > > It is a real property of a data node.
> > >
> > > Note: it is still not clear that such a statement (base or extension)
> > > is needed at all.
> > >
> > >
> >
> > I do not understand why you are so opposed to using real YANG statements
> > to support ephemeral state.
>
> If this solution was already well defined and agreed upon by everyone,
> then it could be done as a YANG statement.  But I am worried that
> adding this will take quite some time, and will thus delay YANG 1.1;
> and since IMO extensions can be used just as well, there is no real
> reason for adding this delay.
>
> > Do you have a better solution that the
> > proposal from draft-haas-i2rs-ephermal-state-reqs-00?
>
> Use a separate ephemeral datastore.
>
> > I don't see it.
> > I am opposed to using extensions to ephemeral state because
> > they are poorly defined in YANG.
>
> Then we should fix this.
>
>
> /martin
>
> > This is OK since they are for
> > defining statements outside the YANG standard.  Normal mechanisms
> > like uses/refine and deviate must be supported.
> >
> > I do see any advantages whatsoever for using external statements
> > instead of YANG statements.
>
>