Re: [netmod] upcoming adoptions
Andy Bierman <andy@yumaworks.com> Thu, 07 September 2017 02:36 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 92B8E1321B6 for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 19:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 nlOS3UbRfZvj for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 19:36:30 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 0541E124319 for <netmod@ietf.org>; Wed, 6 Sep 2017 19:36:30 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id q64so1247798iod.5 for <netmod@ietf.org>; Wed, 06 Sep 2017 19:36:29 -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=aRpImF2ZLuyF+k7WEGtdm8qSJI/K+1+96pKJGlILZfQ=; b=EI07Rb0xUaLzVTT7pLUn2PklUwzF+NtDV1ZzPllYmxwBpF/1IkWB5OKGuGVhwiNO+e ZSyrYXCZ8HXn93UBhbDQBPAMvk3plsSx0TFauXV+APVMW5M42EFNZnUGerMFWK1AC+jk w2mHGu2ly99lgfq70UbXHi22jr7MTw13fe1ulktVVcFEl6UBWpkqTvneWpFbFSm9oqup cTlprGa6k1aQtdu3nOyJHWleCZtZxmPDvAVwwiB0pPEDlW2VTmdDVXNyu/NbXY5fJaJB E+FuBBpExwqn68Bte5JQjNjmaYKC3KJMVBdy4FAywg6LK/3xJ/O1H7EFgJ93e/eYGAia znag==
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:cc; bh=aRpImF2ZLuyF+k7WEGtdm8qSJI/K+1+96pKJGlILZfQ=; b=hwIkyvt7Y7do93tbeLirpU+BHCf5FF0D1p21cV7oX9vNJDmj23TUTlEwwjYqyNhtmj qA2gFsBxV0TyyPMO5ydM4ZM+Glb4GzsGZjLHrBNXG9v8YRfgOx9gM2WZUmyTA4a/8cVW vedXYCsxeN80bGURddYtCYs2d/JEk5voM7r3pRx0FCZDgVrMVqPa09f07Cycikctt9QL Lgafhwek+JwavehEInHGvMyKmAwG/AT16p9cVmGhMCrF03pAr+OdsI+CjRbFamWDUjQl p4DeuzL6zQLXsB5ercIgQrazZa2SZwUebyXtRqs5ATCyVTpRjFj9sVsiEzMBdw4+P3tY YlFA==
X-Gm-Message-State: AHPjjUhD3NptXiOzbyiL04poZ3Li628LVTEl/NrwjRlUo2XYtHQHM8Yz f6GgiWUZ57MPNpRWtjRYGZv7Tu2U/kio
X-Google-Smtp-Source: AOwi7QDQOxWtYEsgCvtUskAkV2DhCQl05rNTqOb90yNU3CPw2NJl9feZpMfQJcyF9FPaxppHJzgx7si4HS4RFCb7t3U=
X-Received: by 10.107.171.70 with SMTP id u67mr1497564ioe.227.1504751789260; Wed, 06 Sep 2017 19:36:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.6.206 with HTTP; Wed, 6 Sep 2017 19:36:28 -0700 (PDT)
In-Reply-To: <A57EC752-3E23-4E8E-A802-C7CDD37A3DD1@juniper.net>
References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <CABCOCHRmNT=v9ivztzPh3OGmo-AeheHDct2XY9zbk_-FjEytmg@mail.gmail.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net> <CABCOCHQ-bBe307BgXJtxKOW3avmdkck4qrmj-oHTdmaRD5pU_w@mail.gmail.com> <A57EC752-3E23-4E8E-A802-C7CDD37A3DD1@juniper.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 06 Sep 2017 19:36:28 -0700
Message-ID: <CABCOCHRcXUkzQb1g3rJzu3byxsASsCMD1ewtOwAbdfoYrZEMhg@mail.gmail.com>
To: Kent Watsen <kwatsen@juniper.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, "bclaise@cisco.com" <bclaise@cisco.com>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a1148bd7adfe17005589053b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rFPXFmlyW6FkZRmERjJaTQBBW_w>
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 07 Sep 2017 02:36:32 -0000
On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <kwatsen@juniper.net> wrote: > > > >> /netconf-state and /restconf-state don't seem to follow the general > >> pattern we're correcting with the various NMDA updates. Particularly, > >> these -state trees are NOT for the purpose to providing the opstate > >> value for configured nodes. These modules have the misfortune of > >> having "-state" in their name, but they're otherwise fine. > > > > > > This contradicts some details we have been told about NMDA > > > > 1) the transition guidelines say otherwise > > > > New modules and modules that are not concerned with the > > operational state of configuration information SHOULD > > immediately be structured to be NMDA-compatible > > Yes, I'm suggesting we give ourselves some leeway, by taking > advantage of the SHOULD keyword above and defer updating these > two modules to when it makes more sense to do so. > > OK -- good. I think another sentence needs to be added. NMDA compatibility conversion MAY be deferred if the module does not contain any configuration datastore objects. > > 2) RD defines operational state to include config=false nodes > > such as counters, so these modules are properly named. > > module-name == top-level node name. Either way, my point is that > the -state tree in these modules is not trying to provide the > opstate value for configured nodes (i.e. applied configuration). > > So a data node naming convention is needed? And a module naming convention? We need a rule that says the suffix "-state" is reserved for NMDA compatibility so module names and data nodes SHOULD NOT be named with an identifier that ends in this suffix. (Automation tools like deterministic rules, not naming conventions. Here is an example why... there are always exceptions that do not follow the conventions. Always people who are unaware of the conventions.) > > K. > > > > Andy
- [netmod] ietf-routing or ietf-routing-2? module n… Benoit Claise
- Re: [netmod] upcoming adoptions - this appendix i… Lou Berger
- Re: [netmod] upcoming adoptions - this appendix i… Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions - this appendix i… Robert Wilton
- Re: [netmod] upcoming adoptions - this appendix i… Robert Wilton
- Re: [netmod] upcoming adoptions - this appendix i… Randy Presuhn
- Re: [netmod] upcoming adoptions - this appendix i… Lou Berger
- Re: [netmod] upcoming adoptions - this appendix i… Benoit Claise
- [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Acee Lindem (acee)
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Benoit Claise
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Martin Bjorklund
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Ladislav Lhotka
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Lou Berger
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Acee Lindem (acee)
- Re: [netmod] upcoming adoptions t.petch
- Re: [netmod] upcoming adoptions Lou Berger
- Re: [netmod] upcoming adoptions Juergen Schoenwaelder
- Re: [netmod] upcoming adoptions Ladislav Lhotka
- Re: [netmod] upcoming adoptions Acee Lindem (acee)
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Robert Wilton
- Re: [netmod] upcoming adoptions - this appendix i… t.petch
- Re: [netmod] upcoming adoptions Andy Bierman
- Re: [netmod] upcoming adoptions Kent Watsen
- Re: [netmod] upcoming adoptions Ladislav Lhotka
- Re: [netmod] upcoming adoptions - this appendix i… Lou Berger
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Martin Bjorklund
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Martin Bjorklund
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Robert Wilton
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Benoit Claise
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Robert Wilton
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Martin Bjorklund
- Re: [netmod] ietf-routing or ietf-routing-2? modu… Kent Watsen
- Re: [netmod] [Rtg-dt-yang-arch] ietf-routing or i… Lou Berger