Re: [netmod] upcoming adoptions

Martin Bjorklund <mbj@tail-f.com> Wed, 06 September 2017 06:43 UTC

Return-Path: <mbj@tail-f.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 36943132357; Tue, 5 Sep 2017 23:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7fNsSi0nzHes; Tue, 5 Sep 2017 23:43:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85E126E7A; Tue, 5 Sep 2017 23:43:00 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5471C1AE0187; Wed, 6 Sep 2017 08:42:58 +0200 (CEST)
Date: Wed, 06 Sep 2017 08:41:24 +0200 (CEST)
Message-Id: <20170906.084124.2282926097915349446.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: bclaise@cisco.com, netconf-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHRmNT=v9ivztzPh3OGmo-AeheHDct2XY9zbk_-FjEytmg@mail.gmail.com>
References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <CABCOCHRmNT=v9ivztzPh3OGmo-AeheHDct2XY9zbk_-FjEytmg@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OoizIKGbrCSqzs_CmKCtiuDZz90>
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: Wed, 06 Sep 2017 06:43:02 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Sep 5, 2017 at 12:59 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > Benoit Claise <bclaise@cisco.com> wrote:
> > > Kent,
> > > > Hey folks,
> > > >
> > > > As discussed at the last meeting, we are heading to revising existing
> > > > RFCs to align them with NMDA.  The first batch have been published as
> > > > individual drafts:
> > > >
> > > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
> > > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
> > > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
> > > Good. And there is one more in for NETMOD, as discussed in
> > > https://datatracker.ietf.org/meeting/99/materials/slides-
> > 99-netmod-sessa-nmda-qa:
> > > RFC 7317
> > > In NETCONF, we have also:
> > >     RFC 6022, no I-D submitted yet
> >
> > I don't think this one requires an update at this time.  *If* it is
> > changed, it might be worthwhile to remove definitions already covered
> > by yang-library, and probably align with the netconf server model.
> >
> > >     RFC 7895, already adopted
> > >     RFC 8040, no I-D submitted yet. No immediate plan to update?
> >
> > We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040".
> >
> >
> 
> This draft does not address ietf-restconf-monitoring.

Correct.  See below.

>
>    YANG tree diagram for the "ietf-restconf-monitoring" module:
> 
>       +--ro restconf-state
>          +--ro capabilities
>          |  +--ro capability*   inet:uri
>          +--ro streams
>             +--ro stream* [name]
>                +--ro name                        string
>                +--ro description?                string
>                +--ro replay-support?             boolean
>                +--ro replay-log-creation-time?   yang:date-and-time
>                +--ro access* [encoding]
>                   +--ro encoding  string
>                   +--ro location  inet:uri
> 
> 
> I guess the NMDA transition plan to move the child nodes to a config=true
> node
> name /restconf that has only config=false nodes in it.  This seems quite
> disruptive
> and not a productive use of engineering resources, or support and customer
> re-training.

I agree with you.  We've said that it is ok to have pure config false
trees, if it makes sense for what we're trying to model.

The only "issue" with the tree above is that its top-level node's name
contains the word "state".

But OTOH, maybe we need to revisit this model for the upcoming new
notification work anyway.  It has a new defintiion of streams, so at
least we need to deprecate the /restconf-state/streams contianer.


/martin



> The /netconf-state container is the same, and many more just like it.
> 
> NEW:
> 
>      +--rw restconf
>          +--ro capabilities
>          |  +--ro capability*   inet:uri
>          +--ro streams
>             +--ro stream* [name]
>                +--ro name                        string
>                +--ro description?                string
>                +--ro replay-support?             boolean
>                +--ro replay-log-creation-time?   yang:date-and-time
>                +--ro access* [encoding]
>                   +--ro encoding  string
>                   +--ro location  inet:uri
> 
>     (+ old tree, but deprecated)
> 
> I doubt vendors will prioritize this high-impact/low-value upgrade, so
> the deprecated foo-state trees will be needed for many years.
> 
> 
> > /martin
> >
> 
> Andy
> 
> 
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >