Hi Alex,
I see no real advantages to putting this directly in YANG library bis,
but I think that augmenting the YANG library bis structure is just fine
(in the same way that the latest version of schema mount has proposed to
do).
Generally, I think that it is good that NETCONF/YANG is built up of
fairly loosely coupled components. E.g. implementations can choose
which subset of features are required for their particular circumstances
(e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).
If over time it becomes clear that it is critical for good interop that
particular features must always be supported then we can define NETCONF
2.0 or 3.0 that mandates that a particular set of technologies must be
implemented to meet the standard.
The added bonus of having these components loosely coupled is that they
can be improved and refined independently, potentially allowing IETF to
move a bit quicker advancing the technologies.
Finally, even if there is common meta-data structure that is shared by
multiple features, that still doesn't mean that it has to go in the base
YANG library spec, that can still just be shared common extension.
Thanks,
Rob
On 13/02/2018 21:25, Alexander Clemm wrote:
My proposal is to add this to the YANG data model. I think this logically
belongs to YANG library which is why I would like to see it there. I also
think it will be useful to many implementations. All, probably not, but they
have also survived without YANG library for a while:-) Of course, it is always
possible to write another draft or do a bisbis.
Cheers
--- Alex
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, February 13, 2018 12:29 PM
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)
I must have missed your actionable proposal that is relevant for _all_ NETCONF
and RESTCONF implementations.
YANG data models are extensible so lets use that.
/js
On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:
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.htm
l
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/>
--
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
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
