IETF Logo Mail Archive

Re: [yang-doctors] Yang syntax for a globally-unique key?

Kent Watsen <kent@watsen.net> Tue, 25 August 2020 19:53 UTC

Return-Path: <01000174272e7b3e-8c389f49-635c-450a-b74d-6c71a890882d-000000@amazonses.watsen.net>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3253A0B41 for <yang-doctors@ietfa.amsl.com>; Tue, 25 Aug 2020 12:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Tkna6-RojzVl for <yang-doctors@ietfa.amsl.com>; Tue, 25 Aug 2020 12:53:13 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D663A0B35 for <yang-doctors@ietf.org>; Tue, 25 Aug 2020 12:53:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1598385191; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=XMBNqgc1WvEOFtGtAgKF4vcoG9ETfDHLg5fcaTYdBqg=; b=RBSTkJtDXe0yQ4NC/Yq9qHE89nZ5xslWFeP4M05888FFaXuphhbmYIJ/URHkkXkg FI3SM3/CZZfXmYoj1Xtm/kxlUM+AVhvAgOr1bzbRtI+BpS++V9sgLbip+OSyKHm8+Rl y0KKaQKehiRpv6W66XeYz1+shLKDrXSVfo6hiKNA=
From: Kent Watsen <kent@watsen.net>
Message-ID: <01000174272e7b3e-8c389f49-635c-450a-b74d-6c71a890882d-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C1EC29E2-D945-4307-85D2-E3B46A4C8AD9"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 25 Aug 2020 19:53:11 +0000
In-Reply-To: <1dab12ae-1f41-10ad-789c-17a38f344efe@nic.cz>
Cc: yang-doctors@ietf.org
To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
References: <0100017425c983cb-d9471cc6-34d3-4a49-ab7b-942bca5ae697-000000@email.amazonses.com> <CABCOCHRhE9EqpgKKHpvkCWrmE4JkQN6i5kAF4EMfXF=GA1EVQg@mail.gmail.com> <df41a832-7ebd-9abf-f9e5-d0838797ded0@nic.cz> <CABCOCHS-1XuWGf8U6z=r+WnTh4zH2qfDhbTX2YaPN2fcZt1twg@mail.gmail.com> <06a32179-128a-99f0-b489-56985679964d@nic.cz> <1dab12ae-1f41-10ad-789c-17a38f344efe@nic.cz>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.08.25-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/GHq1QMHM_ljvPMfNo4A7ov9tH5o>
Subject: Re: [yang-doctors] Yang syntax for a globally-unique key?
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2020 19:53:14 -0000

Hi Lada,

>>>>      Assume data model:
>>>> 
>>>>        +—rw tenants
>>>>            +—rw tenant [key]
>>>>                +—rw  key        string
>>>>                +—rw admins
>>>>                    +—rw admin [name]
>>>>                         +—rw name     string
>> <snip>
>> I don't see any augmentation involved in either case. Anyway, I do agree
>> that the unique statement should work. Otherwise, section 12.16 of RFC
>> 6110 essentially gives what Kent asks for, which is in this case:
>> 
>>    must "not(preceding-sibling::tenant[current()/admins/admin/name])";
> 
> Sorry, it should be
> 
>    must "not(preceding-sibling::tenant[admins/admin/name  =
> current()/admins/admin/name])

I thought "preceding-sibling” was for selecting a sibling?  In my example, “tenant” doesn’t have a sibling, so what is selected?  You *are* putting the must  statement on the “tenant” node, right?


> Lada

K.

v2.23.0 | Report a Bug | By Email