Robert Wilton <rwil...@cisco.com> writes:

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

+1

Lada

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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Reply via email to