From nobody Fri Jun 9 07:00:51 2017 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3087F126BF6; Fri, 9 Jun 2017 07:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Pk2ix3jkau4q; Fri, 9 Jun 2017 07:00:48 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0C21241FC; Fri, 9 Jun 2017 07:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8167; q=dns/txt; s=iport; t=1497016848; x=1498226448; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=ZddvKP8mSuW1EOFw/V6MSLs4nj5t4dNXqMNrqy7+iEE=; b=SkPsbUOjTxo8Tl8uGfQRCEtOhu3p3UX7xDDepVhuCXHeAB2nmeTFrzGZ x/inQ4UkWv3v0ukz1Lpug+8jSs/zRw/je0Go8tJ8ChaVqzULwiDIeY8Nj g0D5+1gyMVnbPpYuf68EzEhFnYKa0vZtUr76jUApuFbWKtRlfxesOWFqk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQDIqDpZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyyBD4ENg3SKGHOQWCGQSoU5ghEshXgCg0AYAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?DAyNLGxwBAgECKwICSQQCCAYBDAYCAQEXihAQsCmCJiuLQAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGQWGYYFgKwuCaoUKgnKCYQWQdo1Ghyhbiz6CBoVDg0uGcowtg1O?= =?us-ascii?q?Eah84gQowIQgbFUgIgXGFFz42hwAqghUBAQE?= X-IronPort-AV: E=Sophos;i="5.39,317,1493683200"; d="scan'208,217";a="653481963" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2017 14:00:45 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v59E0j8H024503; Fri, 9 Jun 2017 14:00:45 GMT References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> To: Routing WG , "Rtg-yang-coord@ietf.org" From: Benoit Claise X-Forwarded-Message-Id: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> Message-ID: <98f55f6d-8365-1ffd-f667-099866265f0d@cisco.com> Date: Fri, 9 Jun 2017 16:00:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> Content-Type: multipart/alternative; boundary="------------59BBB31229DF5458CEDABAA2" Content-Language: en-US Archived-At: Subject: [Rtg-yang-coord] Fwd: Important: Guidelines for YANG module authors X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 14:00:50 -0000 This is a multi-part message in MIME format. --------------59BBB31229DF5458CEDABAA2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, FYI. If this topic requires some discussion, let's use the netmod mailing list. Regards, Benoit -------- Forwarded Message -------- Subject: Important: Guidelines for YANG module authors Date: Fri, 9 Jun 2017 15:56:39 +0200 From: Benoit Claise To: NETMOD Working Group 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 , impacts Yang models. The 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 --------------59BBB31229DF5458CEDABAA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

FYI.
If this topic requires some discussion, let's use the netmod mailing list.

Regards, Benoit

-------- Forwarded Message --------
Subject: Important: Guidelines for YANG module authors
Date: Fri, 9 Jun 2017 15:56:39 +0200
From: Benoit Claise <bclaise@cisco.com>
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, impacts Yang models. The 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
--------------59BBB31229DF5458CEDABAA2--