Re: [netmod] ?= ?==?utf-8?q? mandatory choice with non-presence container cas

Ladislav Lhotka <lhotka@nic.cz> Tue, 25 June 2019 13:14 UTC

Return-Path: <lhotka@nic.cz>
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 14CA41202A6 for <netmod@ietfa.amsl.com>; Tue, 25 Jun 2019 06:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.996
X-Spam-Level:
X-Spam-Status: No, score=-6.996 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 JOeUu4qMXIB5 for <netmod@ietfa.amsl.com>; Tue, 25 Jun 2019 06:14:19 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF221202A4 for <netmod@ietf.org>; Tue, 25 Jun 2019 06:14:18 -0700 (PDT)
Received: from birdie (37-48-32-106.nat.epc.tmcz.cz [37.48.32.106]) by mail.nic.cz (Postfix) with ESMTPSA id 1B04D140843 for <netmod@ietf.org>; Tue, 25 Jun 2019 15:14:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1561468456; bh=DBHY4T4Xobfm0Cd8RvC16lbofIMeh5lrsqgMzuTfp5c=; h=From:To:Date; b=DLFf4dtvcEoAGAIVahr8uPjcNwlcllnM8rumOKmLhomDIfmFqUe7vLV+ZFpfde98h jaYch4Vofzlu2K5GSdZxIfonK8P65qhZKtolVKgdvzTPAQKziPlVKKDVOdSqknmb+Q Sv7/zHR6zu4JlbpNyI8L5MUexMkdYG8+SrRo3PJw=
Message-ID: <41409287f28be0e30e4bc29ef44f755434f6567f.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Tue, 25 Jun 2019 15:14:15 +0200
In-Reply-To: <20190625.135902.1021903277794682233.mbj@tail-f.com>
References: <BYAPR11MB263192DBFAA0F634DBCF0A85B5E30@BYAPR11MB2631.namprd11.prod.outlook.com> <791d-5d120380-25-51599d00@91535824> <20190625.135902.1021903277794682233.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lp2oEpxDN4Dmuk6LKMl9pIMBrhg>
Subject: Re: [netmod] ?= ?==?utf-8?q? mandatory choice with non-presence container cas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 25 Jun 2019 13:14:22 -0000

On Tue, 2019-06-25 at 13:59 +0200, Martin Bjorklund wrote:
> Michal Vaško <mvasko@cesnet.cz> wrote:
> > Hi Rob,
> > actually, I have used model with the container TOP just for
> > simplification, I have encountered the issue while implementing
> > ietf-ssh-server model from its current draft. I have created the
> > container "users" [1] without any "user" list instances. Now, you may
> > argue that this is still not a valid use-case because there are no
> > users but I only tried to satisfy the condition.
> 
> Yes, I think that this list (user) should have a "min-elements 1".  I
> think that matches the i ntent.

Interestingly, the "users" container actually becomes a P-container: its
presence indicates that the corresponding case is selected. It might make sense
for an admin to select this case even before any users are configured.

This example also exposes the drawback of the XML representation - it cannot
distinguish between an empty list and nothing. In JSON, the problems of this
thread could potentially be circumvented by configuring

"users" : {
    "user" : [
    ]
}

Lada

> 
> /martin
> 
> 
> 
> > There are some users
> > on the system but they are generated into the configuration on-demand
> > when operational data is requested.
> > 
> > Regards,
> > Michal
> > 
> > [1]
> > https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14#page-22
> > 
> > On Tuesday, June 25, 2019 11:08 CEST, "Rob Wilton (rwilton)"
> > <rwilton@cisco.com> wrote:
> >  
> > > Hi Michal,
> > > 
> > > It is not the printing of the data that makes it valid/invalid.
> > > 
> > > I don't think that your input data was ever valid, because "container
> > > C" doesn't satisfy the mandatory statement because it isn't a real
> > > data node in the tree - it is instantiated when required and may be
> > > deleted when it is no longer required.
> > > 
> > > I.e. your model has been designed such that it can never be satisfied.
> > > 
> > > 
> > > If your model was instead:
> > > 
> > > container TOP {
> > >   leaf L {
> > >     type empty;
> > >   }
> > >   choice A {
> > >     mandatory true;
> > >     container C {
> > >       leaf L2 {
> > >         type empty;
> > >       }
> > >     }
> > >   }
> > > }
> > > 
> > > 
> > > Then this data is valid:
> > > 
> > > <TOP>
> > >   <L/>
> > >   <C>
> > >    <L2/>
> > >   </C>
> > > </TOP>
> > > 
> > > 
> > > But this data is not:
> > > 
> > > <TOP>
> > >   <L/>
> > > </TOP>
> > > 
> > > 
> > > Nor is this, which is directly equivalent to the one above, because
> > > the <C/> container doesn't really exist if it doesn't have a child
> > > node present.
> > > 
> > > <TOP>
> > >   <L/>
> > >   <C/>
> > > </TOP>
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Michal Vaško <mvasko@cesnet.cz>
> > > > Sent: 24 June 2019 18:15
> > > > To: Andy Bierman <andy@yumaworks.com>
> > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>om>; netmod <netmod@ietf.org>
> > > > Subject: Re: [netmod] ?= mandatory choice with non-presence container
> > > > cas
> > > > 
> > > > Hi Andy,
> > > > 
> > > > On Monday, June 24, 2019 19:11 CEST, Andy Bierman <andy@yumaworks.com>
> > > > wrote:
> > > > 
> > > > > On Mon, Jun 24, 2019 at 10:01 AM Michal Vaško <mvasko@cesnet.cz>
> > > > > wrote:
> > > > > 
> > > > > > Hi Rob,
> > > > > > I think there is a problem in the RFC because using only allowed
> > > > > > steps I got invalid data from initially valid data. That cannot be
> > > > correct.
> > > > > No.  See sec. 7.5.7
> > > > > 
> > > > >    If a non-presence container does not have any child nodes, the
> > > > >    container may or may not be present in the XML encoding.
> > > > > 
> > > > > 
> > > > > Just because your retrieval does not contain the NP-container, that
> > > > > does not mean the NP-container was not present in the server for the
> > > > > mandatory-stmt validation.
> > > > 
> > > > I agree, but these valid data were correctly printed into invalid
> > > > data. I
> > > > do not think printing is allowed to change the validity of data.
> > > > 
> > > > Michal
> > > > 
> > > > > Regards,
> > > > > > Michal
> > > > > > 
> > > > > > 
> > > > > Andy
> > > > > 
> > > > > 
> > > > > > On Monday, June 24, 2019 18:52 CEST, "Rob Wilton (rwilton)" <
> > > > > > rwilton@cisco.com> wrote:
> > > > > > 
> > > > > > > Hi Michal,
> > > > > > > 
> > > > > > > My thoughts:
> > > > > > > 
> > > > > > > According to 7.5.1:
> > > > > > > 
> > > > > > >    In the first style, the container has no meaning of its own,
> > > > existing
> > > > > > >    only to contain child nodes.  In particular, the presence of
> > > > > > > the
> > > > > > >    container node with no child nodes is semantically equivalent
> > > > > > > to
> > > > the
> > > > > > >    absence of the container node.  YANG calls this style a "non-
> > > > presence
> > > > > > >    container".  This is the default style.
> > > > > > > 
> > > > > > > Hence your request (because the NP container does not have any
> > > > > > > children)
> > > > > > is equivalent to:
> > > > > > >  <TOP>
> > > > > > >    <L/>
> > > > > > >  </TOP>
> > > > > > > 
> > > > > > > which fails the "mandatory" check.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Rob
> > > > > > > 
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Michal Vaško
> > > > > > > > Sent: 24 June 2019 17:39
> > > > > > > > To: netmod <netmod@ietf.org>
> > > > > > > > Subject: [netmod] mandatory choice with non-presence container
> > > > > > > > case
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > I have encountered a situation that I think is not covered by
> > > > > > > > RFC
> > > > > > 7950. My
> > > > > > > > specific use-case was as follows.
> > > > > > > > 
> > > > > > > > model:
> > > > > > > > 
> > > > > > > > container TOP {
> > > > > > > >   leaf L {
> > > > > > > >     type empty;
> > > > > > > >   }
> > > > > > > >   choice A {
> > > > > > > >     mandatory true;
> > > > > > > >     container C;
> > > > > > > >   }
> > > > > > > > }
> > > > > > > > 
> > > > > > > > data:
> > > > > > > > 
> > > > > > > > <TOP>
> > > > > > > >   <L/>
> > > > > > > >   <C/>
> > > > > > > > </TOP>
> > > > > > > > 
> > > > > > > > Parsing was successful, but printing these data back to XML
> > > > produced:
> > > > > > > > <TOP>
> > > > > > > >   <L/>
> > > > > > > > </TOP>
> > > > > > > > 
> > > > > > > > and parsing this correctly failed with missing mandatory choice.
> > > > > > According
> > > > > > > > to section 7.5.7 [1], I think the C container could be omitted
> > > > > > > > but the whole situation does not seem correct. Thank you for any
> > > > input.
> > > > > > > > Regards,
> > > > > > > > Michal
> > > > > > > > 
> > > > > > > > [1] https://tools.ietf.org/html/rfc7950#section-7.5.7
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > netmod mailing list
> > > > > > > > netmod@ietf.org
> > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > 
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > 
> >  
> >  
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67