Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Andy Bierman <andy@yumaworks.com> Tue, 12 July 2016 16:17 UTC

Return-Path: <andy@yumaworks.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 1F8DF12D1A9 for <netmod@ietfa.amsl.com>; Tue, 12 Jul 2016 09:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 VcQ75albaXu9 for <netmod@ietfa.amsl.com>; Tue, 12 Jul 2016 09:17:54 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 D1ADB1288B8 for <netmod@ietf.org>; Tue, 12 Jul 2016 09:17:53 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id o63so28893085vkg.1 for <netmod@ietf.org>; Tue, 12 Jul 2016 09:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nBoxOUHbEk4460Esvb3oYyModgzLLdS0NKQFzmHMGO4=; b=HDAlplEUNeatk0gRmWhcxqrzHWccMhOGgxrkY4iGnkKjEMBDi8UNyvnjaEA095aHyy ZV485lVhr75vq1rhlpa5NCQxGpDypjy83wSgSl3TjpNK9rHXtVr9mdJO6+OhJu5EH11D IWCL9cc6BynMg0VbY/Bu1VgGGNclPNX/Z/9Z6+hd2uQybxSwTPWcEZ3uu7Vq90OO/e34 SbQ3BZAYu85kGvryD6jZhMEWByOnAvFLceCNkG33+3cr0V7VkeijGW3nIRseYWU1j4K2 YXY+35ea2soGD7WVzaYbkk43N281DXn/PWh9D6Q0lw3Z7ecXA9R+ZOy+SCMZA5yuJuPX RmwA==
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:from:date :message-id:subject:to:cc; bh=nBoxOUHbEk4460Esvb3oYyModgzLLdS0NKQFzmHMGO4=; b=lHZa4NAAGca0UBpjmixsBYM2sOWlu6AbthKTr1f4rIok+i5isviyP5FWWR6h54zyR8 cnjdlF+Xq5XbbXKtOu3fWWUTE7Z8InEJZv3XVp3M9iXGj8bkg7LKEV2wdl1N9K6d8TDi ymwvGt6OO62I4CQgWATv7OQ1tSOtBZ+JHBM6PZ7MQf51iZSsgUgPvtAOBjnfJ1Okrn2v UjuJGr3rS8+Lx1VISQRRWJP3zj93NFJNNzSCnDF3pYBSSprQfT+nQMaafipe9kLiGLaH 17LQju7kOh7WaGsM+MzFq4sUL2hjf7O3QZQoVBDkvNkAMIofHExrny4rgcPyJLq6yJj4 +mag==
X-Gm-Message-State: ALyK8tKM/llh2kmBXNreZuGVIWY9NFZgJ3OuyPODF2iWAPUFCS59NGKwOKutwStKFxrcYuHo0NK7sW30iyGNLg==
X-Received: by 10.159.36.22 with SMTP id 22mr1575786uaq.105.1468340272647; Tue, 12 Jul 2016 09:17:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Tue, 12 Jul 2016 09:17:52 -0700 (PDT)
In-Reply-To: <02b5661f-22e0-6ccc-89d2-ef0370c4e87c@labn.net>
References: <D3A935F0.6A4DC%acee@cisco.com> <02b5661f-22e0-6ccc-89d2-ef0370c4e87c@labn.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 12 Jul 2016 09:17:52 -0700
Message-ID: <CABCOCHSH5wC3-VbAF6tXOc+3tSxpC3a0MA23YEkUFEBojoo25w@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary="001a11352aaa5c82610537729c27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GKcfW7QNDF7EIQcb4x-cQM7vcho>
Cc: netmod WG <netmod@ietf.org>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Jul 2016 16:17:55 -0000

On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lberger@labn.net> wrote:

> Acee,
>
>     I personally was assuming we'd follow 3, but I'd like to understand
> the implication of 2 as I'm not sure I really understand what you're
> thinking here.  Can you elaborate what you're thinking here?
>
> Thanks,
>
> Lou
> .....
> >   3. #2 plus collapse the config (read-write) and  system-state
> > (read-only) into common containers. No more branching of
> > <model-name>-config and <model-name>-state at the top level of the model.
> >.....



I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary
configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be
co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.  Why is that progress?


Andy