IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 12 July 2016 16:56 UTC

Return-Path: <acee@cisco.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 4600212D1E6 for <netmod@ietfa.amsl.com>; Tue, 12 Jul 2016 09:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Os-2j4MSiD4V for <netmod@ietfa.amsl.com>; Tue, 12 Jul 2016 09:56:55 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4953712D17B for <netmod@ietf.org>; Tue, 12 Jul 2016 09:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12397; q=dns/txt; s=iport; t=1468342615; x=1469552215; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y88t/65G7gQiWTwDlcvFREZEkpq1wGul2974xR5BrVE=; b=XVhrAHBy8JVk0WeeqQlr5lKD0RLJ5qeMmIm/cYOVn3R7BRnACd4a4OiW jHPJXvh6YjfoeXtn0a2bh8hRXJpOwBfOW8Ud5R8k2cP8Mc7Lm5iWosFPR uC7i5WQCiQabfRRg8sqT6ugFCocQ54ItXMN8LLkjvwwrV4ATwa/DezgRr w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BOAgACIYVX/4YNJK1cgnBOgVIGs3+CdYIPgXmGGAIcgRk4FAEBAQEBAQFlJ4RcAQEFI1YQAgEIEQMBAigDAgICMBQJCAIEDgWIMLEUjw0BAQEBAQEBAQEBAQEBAQEBAQEBAQEcineEKzaCYYJaBY4HixQBjlOBaogHhT2QEwEeNoNxbogmfwEBAQ
X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208,217";a="128794170"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 16:56:54 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6CGur1J021783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 16:56:54 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 12:56:53 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 12:56:53 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
Thread-Index: AQHR25JaeXwJZYUBL0Wtuo0RKdx74KAVLrsAgAAPDwD//8BlgIAARVMA///CHIA=
Date: Tue, 12 Jul 2016 16:56:53 +0000
Message-ID: <D3AA9952.6B1FB%acee@cisco.com>
References: <D3A935F0.6A4DC%acee@cisco.com> <02b5661f-22e0-6ccc-89d2-ef0370c4e87c@labn.net> <CABCOCHSH5wC3-VbAF6tXOc+3tSxpC3a0MA23YEkUFEBojoo25w@mail.gmail.com> <D3AA932E.6B1B6%acee@cisco.com> <CABCOCHShir2gV0NQGQ8bFM1HBtGFOC7X3UHEnCewsELNKK6toA@mail.gmail.com>
In-Reply-To: <CABCOCHShir2gV0NQGQ8bFM1HBtGFOC7X3UHEnCewsELNKK6toA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_D3AA99526B1FBaceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7lXPuodhMIBKuCxTZwKe9FElfpg>
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:56:57 -0000


From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:38 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>, netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure



On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Andy,

From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:17 PM
To: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>
Cc: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lberger@labn.net<mailto: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.

If they are meant to be supported independently, why wouldn’t they be separate models?



YANG features can be used and they can still be supported independently.

True - but I have not run across a model featured at the config/state branch.

Acee





Thanks,
Acee


Andy


Why is that progress?


Andy

v2.23.0 | Report a Bug | By Email