Re: [netmod] FW: Comments on draft-ietf-netconf-keystore-07

Martin Bjorklund <mbj@tail-f.com> Mon, 10 December 2018 10:13 UTC

Return-Path: <mbj@tail-f.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 8FF33130F12 for <netmod@ietfa.amsl.com>; Mon, 10 Dec 2018 02:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 N3srVGps8j4q for <netmod@ietfa.amsl.com>; Mon, 10 Dec 2018 02:13:55 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9237A130F00 for <netmod@ietf.org>; Mon, 10 Dec 2018 02:13:53 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C1A141AE034F; Mon, 10 Dec 2018 11:13:50 +0100 (CET)
Date: Mon, 10 Dec 2018 11:13:50 +0100 (CET)
Message-Id: <20181210.111350.1275704126944823868.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <96290FC7-159F-42D4-BD6B-9159EEA8A447@juniper.net>
References: <DB7PR07MB49535839F84D99D318D4D921F8A90@DB7PR07MB4953.eurprd07.prod.outlook.com> <96290FC7-159F-42D4-BD6B-9159EEA8A447@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_bmAy1eESh0eBrj9UIutjm68FMg>
Subject: Re: [netmod] FW: Comments on draft-ietf-netconf-keystore-07
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: Mon, 10 Dec 2018 10:13:58 -0000

Kent Watsen <kwatsen@juniper.net>; wrote:
> YANG experts,
> 
> Why are action/notification statements not allowed under a case
> statement?  Yes, it’s simple to assert, but was it considered, in such
> cases, to instead allow them to attach/bind to the closest legal
> ancestor?  Would it make sense?

There are some corner cases that don't make sense, e.g.:

  choice a {
    case b {
      action foo;
    }
    ...
  }

So we would have to say that the case must have at least some other
node as well, e.g.:

  choice a {
    case b {
      leaf bar {
        type string;
      }
      action foo;
    }
    ...
  }

But the semantics are not quite clear, imo.

> Nit: It would’ve been helpful if the “Since a” paragraphs quoted below
> referenced sections 7.1.1 (The module's Substatements) and 7.9.2.1
> (The case's Substatements)...
> 
> PS: Neither `pyang` nor `yanglint` catch this misuse.

Thanks, now fixed in pyang.


/martin


> 
> Kent // contributor
> 
> 
> On 12/6/18, 5:39 AM, "Dhanapal, Ramkumar (Nokia - IN/Chennai)"
> <ramkumar.dhanapal@nokia.com<mailto:ramkumar.dhanapal@nokia.com>>
> wrote:
> 
> Hi Kent,
> We see the following definition in draft-ietf-netconf-keystore-07.
> 
> grouping local-or-keystore-end-entity-cert-with-key-grouping {
>        description
>          "A grouping that expands to allow an end-entity certificate
>           (and its associated private key) to be either stored locally,
>          within the using data model, or be a reference to a specific
>           certificate in the keystore.";
>        choice local-or-keystore {
>          mandatory true;
>          case local {
>            if-feature "local-keys-supported";
>            uses ct:asymmetric-key-pair-grouping;
>            uses ct:end-entity-cert-grouping;
>          }
>          case keystore {
>            if-feature "keystore-supported";
>            leaf reference {
>              type ks:asymmetric-key-certificate-ref;
>              description
>                "A reference to a specific certificate, and its
>                 associated private key, stored in the keystore.";
>            }
>          }
>          description
>            "A choice between an inlined definition and a definition
>             that exists in the keystore.";
>        }
>      }
> 
> In ct:asymmetric-key-pair-grouping, 2 actions are defined.
> In ct:end-entity-cert-grouping, 1 notification is defined.
> 
> But w.r.t. RFC7950 references below, looks like it is not okay to have
> either actions or notifications in “case” statements.
> 
> https://tools.ietf.org/html/rfc7950#section-7.15<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950-23section-2D7.15&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5MdSdliP9J3hgvGhkGCct2XcKpZ02-EvBh7-1XguBpc&s=UNvfZFjpmFaI7esgjHxrocBZttgjQ5vyfn2E_TkrxFo&e=>
> 
>         Since an action cannot be defined at the top level of a module or in
> 
>         a "case" statement, it is an error if a grouping that contains an
> 
>         action at the top of its node hierarchy is used at the top level of a
> 
>         module or in a case definition
> 
> 
> 
> https://tools.ietf.org/html/rfc7950#section-7.16<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950-23section-2D7.16&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5MdSdliP9J3hgvGhkGCct2XcKpZ02-EvBh7-1XguBpc&s=rQNBqLPet_vEb3FYg0E01BhnxdNQ0u21b4frMZ6WodM&e=>
> 
>         Since a notification cannot be defined in a "case" statement, it is
> 
>         an error if a grouping that contains a notification at the top of its
> 
>         node hierarchy is used in a case definition.
> 
> 
> 
> Can you please check and provide your feedback? Or Am I missing
> something here?
> 
> 
> 
> Thanks & Regards,
> 
> Ramkumar
>