Re: [netmod] upcoming adoptions

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
> >