Well, we need a general solution for that.  YANG-push is just one use case.  
There are other cases where there will be "metadata" (that does not pertain to 
instance data)  and capabilities that clients want to discover.  YANG library 
(in itself providing "metadata" about what a server supports and is capable of) 
is an excellent place to maintain this information.  It also provides the 
opportunity to be systemic about it, as opposed to requiring everyone to define 
their own little custom extensions.  
--- Alex

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 11:48 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: Mahesh Jethanandani <mjethanand...@gmail.com>; NETCONF WG
> <netc...@ietf.org>; NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> 
> Alexander,
> 
> I disagree. This YANG Library is mandatory for all implementations; what you 
> talk
> about seems to concern only implementations that support YANG push. Hence,
> this is an extension that should go in its own module.
> 
> /js
> 
> On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
> > Hi,
> >
> > I have taken a look at this document.
> >
> > My main comment is that one aspect that is missing, that I believe should be
> added, concerns the inclusion of certain metadata about the modules.
> Specifically, in the context of YANG-Push we had a discussion about being 
> able to
> mark nodes that are notifiable on change.  This is just one particular use 
> case of a
> more general issue; in YANG-Push after much debate the conclusion was for now
> to simply make implementors aware of this issue and advise that a solution to
> this must be provided, with the clear understanding that eventually a standard
> solution should be defined.
> >
> > Since the goal of YANG-Library is to allow clients to find out what is 
> > actually
> supported on a given server, this is the right place to keep this 
> information.  One
> possible way to address this would be, for a given module, to maintain a list 
> of
> "meta-info", with a key "meta-tag", and a list with references to the nodes to
> which the metadata applies.  In the case of notifiable-on-change, you would 
> have
> a list with one entry "notifiable-on-change", and then the list with the node
> definitions to which this tag applies.
> >
> > Editorial nit:
> > 2nd paragraph Introduction: informaton --> information
> >
> > Thanks
> > --- Alex
> >
> > From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Mahesh
> > Jethanandani
> > Sent: Thursday, February 01, 2018 11:00 AM
> > To: NETCONF WG <netc...@ietf.org>
> > Cc: NETMOD WG <netmod@ietf.org>
> > Subject: [Netconf] LC on YANG Library (bis)
> >
> > WG,
> >
> > The authors of rfc7895bis have indicated that they believe the document is
> ready for LC[1].
> >
> > This starts a two week LC on the 
> > draft<https://tools.ietf.org/html/draft-ietf-
> netconf-rfc7895bis-04>. The LC will end on February 15.
> >
> > Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you have 
> concerns
> about the document, please state those too.
> >
> > Authors please indicate if you are aware of any IPR on the document.
> >
> > Thanks.
> >
> > [1]
> > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> >
> > Mahesh & Kent
> >
> 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

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

Reply via email to