Re: [netmod] [Netconf] LC on YANG Library (bis)

Robert Wilton <rwilton@cisco.com> Wed, 14 February 2018 10:10 UTC

Return-Path: <rwilton@cisco.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 39E3512783A; Wed, 14 Feb 2018 02:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 saHSSGP73VuB; Wed, 14 Feb 2018 02:10:46 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4E3126CF9; Wed, 14 Feb 2018 02:10:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6811; q=dns/txt; s=iport; t=1518603046; x=1519812646; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=DZtBPzJZhNI/6fkVNHD1rm8FXo0SGdKotpCbBvWi1RE=; b=Rv66bkiOay/7kQ6a84bjhDc2yfM3o++0ChYgCaIHYvRB1sVbD2FougHE RoBP2dbNCi61kty/zLA6qef13CbvcZvJUvqPrSLZXXR6akXAkQw0OnhRH D+ugffwQGWq+Gcx0XuabpfZYzqu9qlhja3otdGdU5gk/lfW1xprwa+n5A 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAJCoRa/xbLJq1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEOHAog2WLGI8PgReHf5BbChgLhElPAoNHFQECAQEBAQEBAms?= =?us-ascii?q?ohSMBAQEEAQEhBAsBBTYLDAICCxABBAEBAQICIwMCAhsGBh8JCAYNBgIBAReKA?= =?us-ascii?q?gMVELAHgW06hQGCQA2BMoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQqDcoN?= =?us-ascii?q?sghGCTzaCa0QBAQECgU4BAQg3JoJQgmUFo3o1CYggiFqFC4IfhiqDc4gJjgJIg?= =?us-ascii?q?TaIGYE8NSOBUDMaCBsVPYJGhHdBNwGLJ4I+AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,511,1511827200"; d="scan'208";a="2063126"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 10:10:43 +0000
Received: from [10.63.23.94] (dhcp-ensft1-uk-vla370-10-63-23-94.cisco.com [10.63.23.94]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1EAAh2H003179; Wed, 14 Feb 2018 10:10:43 GMT
To: Alexander Clemm <alexander.clemm@huawei.com>
Cc: NETCONF WG <netconf@ietf.org>, NETMOD WG <netmod@ietf.org>
References: <F10CE657-FC6B-491B-A8DF-0CFEE98B863C@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com> <20180213202858.uvowmjtx2uk4snyz@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <ef474a50-228a-f18a-db0c-277630678de4@cisco.com>
Date: Wed, 14 Feb 2018 10:10:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kt8pL9O_ZOHNVFI7umg4TkCyUtU>
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
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, 14 Feb 2018 10:10:48 -0000

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.schoenwaelder@jacobs-university.de]
>> Sent: Tuesday, February 13, 2018 12:29 PM
>> To: Alexander Clemm <alexander.clemm@huawei.com>
>> Cc: Mahesh Jethanandani <mjethanandani@gmail.com>om>; NETCONF WG
>> <netconf@ietf.org>rg>; 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.schoenwaelder@jacobs-university.de]
>>>> Sent: Tuesday, February 13, 2018 11:48 AM
>>>> To: Alexander Clemm <alexander.clemm@huawei.com>
>>>> Cc: Mahesh Jethanandani <mjethanandani@gmail.com>om>; NETCONF WG
>>>> <netconf@ietf.org>rg>; 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-bounces@ietf.org] On Behalf Of
>>>>> Mahesh Jethanandani
>>>>> Sent: Thursday, February 01, 2018 11:00 AM
>>>>> To: NETCONF WG <netconf@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
> .
>