[i2rs] Fwd: [netmod] Important: Guidelines for YANG module authors

Alia Atlas <akatlas@gmail.com> Fri, 09 June 2017 15:06 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4412946B for <i2rs@ietfa.amsl.com>; Fri, 9 Jun 2017 08:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7G3aO2w6qqyH for <i2rs@ietfa.amsl.com>; Fri, 9 Jun 2017 08:06:20 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 2EC65127ABE for <i2rs@ietf.org>; Fri, 9 Jun 2017 08:06:18 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id q97so36483902wrb.2 for <i2rs@ietf.org>; Fri, 09 Jun 2017 08:06:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xcijNbPssAKo4lvTbCExboZuaP2fSK62ZPUDscCkqAQ=; b=BX5vYOC5OVDNBIZwgg+I7uLEaeVI/1tQH6HpMHowgOUa2lvBjcpYNUa9hjZOkW8gsg 3owTyQCP9WxuzH0XgXBlTvY0V0QgGj5CZjrcp4hPRNijfCcb/QOiesX1YhLtQk6+lcyl 1TV+VWvWeEPPJ1bW/6c0fQOHbbNWaMSaMylx3tcRSQW/L1XdzNFFA4Tw88SZf5zFepdm GvgLYU5Pke/4SVea/SDk4CEwTUmV07Kt5I0tlVjt5tUZqY9reEoY+6iY0qFOBu+jzCPY dGpO73X5zIv3GlOxB06i911p/wpDA/Y8k2xcCLeXQgNkiGurjX5/AjNaskm+SKR/P1JK QR5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xcijNbPssAKo4lvTbCExboZuaP2fSK62ZPUDscCkqAQ=; b=UEVdUTC0SKhpGM7pnGe66Ks+rlN33evUr0tUij8y/Tz+p6PPxapFzWtHyUmyToCVT0 bGpAPOAIsa+5euI8nlbNfxIT3fzCP+m+Unxa4uOgQTZWn/Yg+0Q7+I2lNDSfdcVR+dcy RFwvQa7uD7VeBf4bXEhvr61xV3rwJ6B3TsjS3tQvpV3Mp9DEXgSvD8h7A8htZLCUQB1k pErvTwtZVKRGeKRPt4VHZGLJpBXBcCedl7AX/ukXMwCAUJAcyim9K3dvGmMjHtDO7riw G2b9LIulvWn+sCzjYPHQ+ey5CqCGPn6DjGmzJMm1CfNbGN29zz4TncCnt9bA34XNaMw+ LnNw==
X-Gm-Message-State: AODbwcATbgRFJGmDA8d5x8CN92IInzbT6zZez3pTbmiAlm1BdKIQuakv LCVobDLDgBzKHe3iifeCbc2z/SFsayFv
X-Received: by 10.223.163.27 with SMTP id c27mr17633475wrb.85.1497020776533; Fri, 09 Jun 2017 08:06:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.131.66 with HTTP; Fri, 9 Jun 2017 08:06:15 -0700 (PDT)
In-Reply-To: <CAG4d1re4XBZcTmigN68EODVZP6C44=t+WDnD8YSW1R=qbM+jzQ@mail.gmail.com>
References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> <CAG4d1re4XBZcTmigN68EODVZP6C44=t+WDnD8YSW1R=qbM+jzQ@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 09 Jun 2017 11:06:15 -0400
Message-ID: <CAG4d1rdUVugrtpkH-1VGFX4cmivL4Tgz=UPX3a-CLVsbgNt8Uw@mail.gmail.com>
To: "i2rs@ietf.org" <i2rs@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f21b09b53d70551884f7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/2rMT4NRKOvEMYEjJa-VJquZd9Hw>
Subject: [i2rs] Fwd: [netmod] Important: Guidelines for YANG module authors
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2017 15:06:22 -0000

---------- Forwarded message ----------
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, Jun 9, 2017 at 11:05 AM
Subject: Fwd: [netmod] Important: Guidelines for YANG module authors
To: "rtgwg@ietf.org" <rtgwg@ietf.org>


At IETF 98 in RTGWG, I mentioned the need for clear guidelines to handle
the changes coming for structuring YANG models.  This is the resulting
guidance.

Regards,
Alia


---------- Forwarded message ----------
From: Benoit Claise <bclaise@cisco.com>
Date: Fri, Jun 9, 2017 at 9:56 AM
Subject: [netmod] Important: Guidelines for YANG module authors
To: NETMOD Working Group <netmod@ietf.org>


Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time
to think about the guidelines for YANG module authors.

The Network Management Datastore Architecture (NMDA) addresses the
so-called "OpState problem" that has been the subject of much discussion in
the IETF. NMDA is still in development, and there will be a transition
period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design
Team have worked with Alia and Benoit to create initial guidelines for how
the NMDA, as defined in draft-ietf-netmod-revised-datastores
<https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>,
impacts Yang models. The draft-dsdt-nmda-guidelines
<https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/> individual
draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to
work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG
Chairs, that models SHOULD move as quickly as possible to the NMDA. The
specific approach to be taken for models being developed now and during the
NMDA transition period should be based on both the expected usage and the
maturity of the data model.

1. New models and models that are not concerned with the operational state
of configuration information SHOULD immediately be structured to be
NMDA-compatible.

2. Models that require immediate support for "in use" and "system created"
information SHOULD be structured for NMDA. Then derived versions of these
models SHOULD be created, either by hand or with suitable tools, that
follow the current modeling strategies. In some cases, the non-NMDA model
may be an existing model and not derived from the NMDA model. In all cases,
the NMDA and non-NMDA modules SHOULD be published in the same document,
with NMDA modules in the document main body and the non-NMDA modules in an
Appendix. The use of the non-NMDA model will allow temporary bridging of
the time period until NMDA implementations are available. The non-NMDA
module names should include ’-state’ appended.

We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin
Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder,
and all others who helped develop these guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod