Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

Ladislav Lhotka <lhotka@nic.cz> Wed, 17 June 2015 12:34 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 01D971A8F4B for <netmod@ietfa.amsl.com>; Wed, 17 Jun 2015 05:34:55 -0700 (PDT)
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 jnpD_PcVCd_w for <netmod@ietfa.amsl.com>; Wed, 17 Jun 2015 05:34:53 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD361A8F46 for <netmod@ietf.org>; Wed, 17 Jun 2015 05:34:53 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 63178181397; Wed, 17 Jun 2015 14:34:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1434544491; bh=DufjYfmGQtonB0c8uE0MwBsoNUQDqUF8v1y4vFwbK9g=; h=From:Date:To; b=uw2R43uQnZ8q2hOamu/A6oeT36QAlR4pgl8w5JLForlDC1wLUOIPLgF/XQ7t7MWhX 98Mg4N+ErwOHN9NKHMIdvuwcKfhy3comuIVfmMANkMRHDNn6x1bHXa9Xry8Qbo4D0A pTpgUF7VIZt1JISobgiR0gIG3JgLxb97JVeTKaEI=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20150617115109.GC21292@elstar.local>
Date: Wed, 17 Jun 2015 14:34:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D6394A6-06D1-4275-8151-E1C34DB20965@nic.cz>
References: <D1A4CEBA.B22F8%kwatsen@juniper.net> <20150617.095439.2211831130594238981.mbj@tail-f.com> <m2vbem4ryj.fsf@nic.cz> <20150617.121216.1211666276307602571.mbj@tail-f.com> <7E9BC65B-8A73-4352-87C7-8A826EFAC45B@nic.cz> <20150617115109.GC21292@elstar.local>
To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.2098)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9z3YIQQmqqdkeIALe__2LDSLJ0o>
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
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, 17 Jun 2015 12:34:55 -0000

> On 17 Jun 2015, at 13:51, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> On Wed, Jun 17, 2015 at 01:41:56PM +0200, Ladislav Lhotka wrote:
>> 
>> 
>> Well, but it is exactly what Kent objected against. It is the requirement to support “old clients” that causes the trouble here (and elsewhere). If client A sets “inactive” somewhere, then the datastore semantics will change also for client B that doesn’t understand “inactive” and may be wondering why the server ignores his edits.
>> 
>> I understand (although RFC 6241 doesn’t say it explicitly) that, unlike YANG extensions, a NETCONF capability advertised by the server can be mandatory for the client in the sense that it has to understand and honour it.
> 
> There is no way for a client to tell whether a certain capability URI
> (it has never seen before) is mandatory to understand or not. In fact,

So it means that, e.g. the annotations from

https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00

cannot be safely used by the server even after advertising them via :conditional-enablement capability. 

> I would say in a proper solution it would be the server would have to
> close the connection if it finds a client that does not understand its
> language. And yes, we are on very slippery grounds here. If
> implementors can create arbitrary cool 'annotations' that break
> clients that do not understand them, we will loose interoperability.
> 
>> A conclusion of this may be that it makes no sense to define
>> annotations through YANG extension after all. On the other hand, I
>> do see a value of having annotations defined in YANG modules.
> 
> Without further protocol support to negotiate annotations, I think
> annotations must be limited to things that can be safely ignored by a
> client. I have not read the I-D yet but I would expect that it should
> say something like that. ;-)

But it’s not a specific problem of this draft, it would simply mean that annotations that cannot be ignored cannot be used at all, no matter what. However, some annotations that have been proposed (and probably used in the wild) are of that sort.

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