IETF Logo Mail Archive

Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00

Ladislav Lhotka <lhotka@nic.cz> Wed, 21 January 2015 10:37 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9968E1A19F4 for <netmod@ietfa.amsl.com>; Wed, 21 Jan 2015 02:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level:
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 k76qWd9rD7V4 for <netmod@ietfa.amsl.com>; Wed, 21 Jan 2015 02:37:35 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03ED1A0673 for <netmod@ietf.org>; Wed, 21 Jan 2015 02:37:34 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id 8E9CE13FD88; Wed, 21 Jan 2015 11:37:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421836653; bh=O0XTVARxhwy2KHt0Yv1+XzGLTOTaU0wON/s5+tfJWxM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dYQ4Q+IhIoxIf6loON0HYhPdCFJ3yzHC6corv+7f5eyLcapBEp8fo8tDy2xEu1Y4h x53bZIypW9YGNTQbEHAGcmir41KpYejGFyt+c9jHjHAnuok6ksqJZYb4bcXahE6wMB VQ2lQYQwVUcZ9jgl6mY36HxEyTSlzVYYgexy7g3o=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20150121103154.GA32345@elstar.local>
Date: Wed, 21 Jan 2015 11:37:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <130009F7-7BFA-4567-93A0-DECB91278591@nic.cz>
References: <20150106212118.GB11692@elstar.local> <D0D1D9F4.8EDBB%kwatsen@juniper.net> <m2h9w1bra6.fsf@nic.cz> <20150121103154.GA32345@elstar.local>
To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1993)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9V5tT5ZY6nNC7spU5SdtWmNhFJg>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 21 Jan 2015 10:37:36 -0000

> On 21 Jan 2015, at 11:31, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> On Thu, Jan 08, 2015 at 09:38:57AM +0100, Ladislav Lhotka wrote:
>> Kent Watsen <kwatsen@juniper.net> writes:
>> 
>>>> - who believes a mechanism to define metadata annotations
>>>>   should be standardized
>>> 
>>> 
>>> Not yet.  
>>> 
>>> First I think we need to clear the way for attributes to be used safely.
>>> We used attributes in <edit-config> and also with-defaults, but in both
>>> cases the client either accepted the contract of the protocol (base:1.1)
>>> or explicitly opted into receiving the attributes (report-all-tagged).
>>> Specifically, what happens to a legacy client if the attribute MUST be
>>> semantically understood (e.g., the enabled/inactive) in order to correctly
>>> process the data?   Even if we don't care about the client, we might
>>> want
>> 
>> You are right but I think we have two separate issues here:
>> 
>> 1. Annotations are defined via an extension, and that by definition
>>   means the client is free to ignore them.
>> 
>> 2. The existing sentiment of letting a (legacy) client pick only a
>>   subset of modules from those advertised by the server means that the
>>   client in any case cannot be expected to support an annotation that
>>   is defined in a YANG module.
>> 
>> As for #1, it would help to make "annotation" a built-in statement, and
>> that was actually one of the questions I asked earlier:
> 
> I believe we need to work with extensions, we can't revise the YANG
> specifications each time an addition is needed.
> 
> My understanding is that this particular extension provides the
> mechanics to define and encode metadata. It will be up to concrete
> metadata definitions to figure out how to make things work such that
> ignorant clients and servers will continue to function.

Fine with me.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

v2.23.0 | Report a Bug | By Email