[netconf] Questions about RFC 8040 example B.3.9

Henning Rogge <hrogge@gmail.com> Wed, 03 June 2020 07:03 UTC

Return-Path: <hrogge@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E343A08B9 for <netconf@ietfa.amsl.com>; Wed, 3 Jun 2020 00:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BQrGeh6klXWD for <netconf@ietfa.amsl.com>; Wed, 3 Jun 2020 00:03:58 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 DCEB03A08A7 for <netconf@ietf.org>; Wed, 3 Jun 2020 00:03:57 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id u16so617682lfl.8 for <netconf@ietf.org>; Wed, 03 Jun 2020 00:03:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=p75sxrJ+PtkdKPMHWWnOEYU1mf+ucBsQ6lF2/jBuFbE=; b=aKQhTtVAm07IH242vCo+wdcYLr6ZOtlQsn9B3vFAmaOUA3MjRCuk2AwbGeaak/J5wM lABJWB4mTjnajcqVWG5NxnDv8UTpdga2+nU6fckJ1dqU1nIQQoPJDOc64p3q144WssbN ehebayVs138ty8RiMTWos27MrvPXdh/ZCxTNILkbxKrb3xnJRnKjsuyrGDcPdY6TTNAz XhdabQ6SbIdScvjJKUBQLHYlsjMbwXw1SCcrs7+tZ7C4awYmLscQC1e3PncLTpLcJuKj vIV2fhY3fnfIsy1rspSGK7ssR+h+GqC1Jjo1CGjj9YsuqLKiOpuwGhgHNbJ5y75JTtil 0qIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p75sxrJ+PtkdKPMHWWnOEYU1mf+ucBsQ6lF2/jBuFbE=; b=UnnDoVl8z7IbCfEOpLEbNx/uS//1ERbJKdanlXZ8GRe3jPdurPzQ0FZFOHEFT4Dd97 rzei75GLS0thPP7aGb/PhOok2QXLeUGYPkXrMX7o453HfhoaudNIXO/jBKBrdP5a3fQX Svd9RB3Sc8tULDjUttNBHoxsBrIePOZD1nfQRcPe18WhEmJoPKZmww1a/RSwf8ENrgsR UWxfefJoh53lXh0x3zmv2W3J9DuZxmfQARH/roA7SITOTGQTKS8JNwX8d2WbTfe5uRTW p2iIk+7UhW9Hx16H2ciaxAIm7FLmKQikRRHW46l81o4p9VIsRR5P8Umj2d+MJzIQVYgF oeHQ==
X-Gm-Message-State: AOAM533kwOZqCM+qokduHC2zLvODEkdEfyFs6LKGvCd2vvBfsYYIJjz7 A5FcVRRQpo+mMvCsNoE9Y+rhG1aPIBRbUQm1ZvlKN14P1kA=
X-Google-Smtp-Source: ABdhPJwLls337bCvaEwnYZw5+TboBRLSMnkgC/GevykM0Y3RCF85ENe6rdGoV0gTCwaVuFl7q+c+sgPSoRRKyZEH0gs=
X-Received: by 2002:a19:c505:: with SMTP id w5mr1648207lfe.201.1591167835496; Wed, 03 Jun 2020 00:03:55 -0700 (PDT)
MIME-Version: 1.0
From: Henning Rogge <hrogge@gmail.com>
Date: Wed, 3 Jun 2020 09:03:29 +0200
Message-ID: <CAGnRvuo8pJp-Q3JHnPOQUf2cxoXa=3sj5n7LaK7OJ3OOFKMaig@mail.gmail.com>
To: Netconf <netconf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9p6i7PXntoaKz1WUUEJGIKraX7c>
Subject: [netconf] Questions about RFC 8040 example B.3.9
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 07:03:59 -0000

Hi...

I am currently implementing all the "with-default" modes in my server
and stumbled over a couple of questions with example B.3.9.

First, the yang model in RFC 6243 A.1. defines the status enum with
the values "ok", "waking up", "not feeling so good", "better check it
out" and "better call for help" (with "ok" the default).

RFC 8040 B.3.9. uses the value "up"... which is undefined (and unclear
if it should be a default value or not).

Second, both results in B.3.9. have a JSON array around the value of
the "example:interface" section... I would expect the result of the
first example to be

{
    "example:interface" : {
        "name" : "eth1",
        "status" : "up"
    }
}

if "up" is a valid but non-default value for status.

Same problem with the second example.

The problem with "up" versus "ok" is also present in the RFC 6243
examples in section A.2.

Henning Rogge