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

Andy Bierman <andy@yumaworks.com> Thu, 30 July 2015 17:58 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 3F76B1ACD54 for <netmod@ietfa.amsl.com>; Thu, 30 Jul 2015 10:58:39 -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 zllRG4tZQ2fM for <netmod@ietfa.amsl.com>; Thu, 30 Jul 2015 10:58:37 -0700 (PDT)
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 07E051ACD50 for <netmod@ietf.org>; Thu, 30 Jul 2015 10:58:37 -0700 (PDT)
Received: by laah7 with SMTP id h7so29749084laa.0 for <netmod@ietf.org>; Thu, 30 Jul 2015 10:58:35 -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=KXA39UNTut7u5KTk1rXvo5RT03VxYzOhmkN7T5l/Ms8=; b=eWgyBnbgGfPxKzFihjvg+t76kyFyM6GfxcR/ZYnR4lcbBkjxwm3OgNYqlme8dNuw54 fvuWNqMbld8Uc+HWhHewMxOTSB6USPPgRYCgwMHQZhz7hXrAXfGrWZbYlvqTGJ6HSOxr 388t1WYWtJP5grtZQUnqO/dTZmRSFaODBXfUT1QXboLWjn2jCDKwmG8F8zbSOGLHtz4K jN92/vV8blhWgVcx2gxnKfWOlEcAXroIb/R7NInk7WZOFxlq3mmeP+65ovgU2F+deLM2 PNWYaKqI348fcm2kLAbrQo6nYVTeb4hu7eEoZcrOD0zuXu6Oap3I7jei7lNpKHUYGk// wRPQ==
X-Gm-Message-State: ALoCoQnLCVEH2FtEh/cynCfgZDKUsaynT8k/JVVdOo/bH2fso9d9vqE13AuMgevHM33p8uQfVV/g
MIME-Version: 1.0
X-Received: by 10.152.36.161 with SMTP id r1mr45231840laj.88.1438279115477; Thu, 30 Jul 2015 10:58:35 -0700 (PDT)
Received: by 10.112.200.102 with HTTP; Thu, 30 Jul 2015 10:58:35 -0700 (PDT)
In-Reply-To: <20150730.194130.1378875555824248389.mbj@tail-f.com>
References: <CABCOCHRqyz1t07ssUBzusiWk_rztj8=NciVvjqh1SYaYQHKkyA@mail.gmail.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <CABCOCHSPZQMJ2dt1AWLWdx0zfukn+qJ3RUzd_P5X=-BEYyyTfw@mail.gmail.com> <20150730.194130.1378875555824248389.mbj@tail-f.com>
Date: Thu, 30 Jul 2015 10:58:35 -0700
Message-ID: <CABCOCHQrZqxKM6cBzij6hWzMUa8DbKSAULr5gW3fhBBV_OZjRw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="089e0158b5e4c42bfd051c1b7320"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/-uIaiX4I9W2fRdKOigi2GNuGaeQ>
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 17:58:39 -0000

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.




> 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.  Do you have a better solution that the
proposal from draft-haas-i2rs-ephermal-state-reqs-00?  I don't see it.
I am opposed to using extensions to ephemeral state because
they are poorly defined in YANG.  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.



> /martin
>


Andy