Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
Andy Bierman <andy@yumaworks.com> Mon, 12 February 2018 19:44 UTC
Return-Path: <andy@yumaworks.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 94F1C1200F1 for <netmod@ietfa.amsl.com>; Mon, 12 Feb 2018 11:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 ryo45Q3wKbiX for <netmod@ietfa.amsl.com>; Mon, 12 Feb 2018 11:44:44 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455871274D2 for <netmod@ietf.org>; Mon, 12 Feb 2018 11:44:44 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id q194so21969405lfe.13 for <netmod@ietf.org>; Mon, 12 Feb 2018 11:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vYIGgyE1rRMk4FnCzn/JXpAFlss1THHmDMqZQBbFEkQ=; b=ULpv5dEmXjLn1RygCvjnuBuaTZ5myCJMwdwhS4L0ORJHOXOctdmG4Px4rXEGorRHo1 a4tRxxIOMR8NQ7dFxbvsUeLPMnQYCSQ5hVzL61pNST3feDw7zX+2QNOj/NoZmCT/Wbmo 3qoVUmkAU5Hen7nT1JVCBxUiTgwXkibD9zBzOYnc9jkBb7DEHSLARD5aOoOUWmpbp8WL TwSwXQufKA4pBXtL/re4eafKzHclPwNhZyFmmaKtgX0crTX+faChjbSSod51zwWNDGr2 xuuLVm9Q7a/e277nr7uNdALlPVMf4CEvvrv+lwZBguWdjH80+aeV/fofcR5Rui5JFFjR hmEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vYIGgyE1rRMk4FnCzn/JXpAFlss1THHmDMqZQBbFEkQ=; b=p14UE2jstO3w6jYwGSYGw02eE2Om7D3tWq5DBEGvMBKZuPpwkHWvmruQPXTgqjG7uu qmSXwiUbIPkoEtKIKdMcYuVqywojA65MGTQS8Ieu9kv3ar/dcMCJ8XxWFBjuW8x51aik KHZu1EOScZjQ3tG9Tm1ymTYLafmZ0fre/sZ6BDXQf1svwzPSMu6V7/mPhL5LE9aiTp8Q 2EN89ZCkq01lcnnbp6ytVN8ZTOv6aq6BA5bvkXOSUHXnb9qG2fW9Sw77K8x//4Bm/hF3 CIy0x/bZ2cWt6HxDOci3CnaGiic4gav8LSBkNSGk9Wd2A9pxBc1Kx3luWtK3Mu1TCGcw TTfQ==
X-Gm-Message-State: APf1xPDezSL+7zCme2RHMuscbzWXQR0IAd0UjLWis1/3vClpoiAqV2bB kxfaqpRDr7aUEM79Mk/7CiumaqKy6pvTKBo+/hlLgQ==
X-Google-Smtp-Source: AH8x226Dnc+ESIoow4YAri4VcfEKfQyht7LR3kwd3VzEPozEVCEBlaQ9KKcVlzR2hP1Hnb+/M911GWQ8RE+br3o1Yhw=
X-Received: by 10.46.83.4 with SMTP id h4mr8464225ljb.47.1518464682430; Mon, 12 Feb 2018 11:44:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Mon, 12 Feb 2018 11:44:41 -0800 (PST)
In-Reply-To: <20180212172936.lt2stijpxgk6o3ug@elstar.local>
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz> <20180212143749.vmjwgtx2lgxxgbcw@elstar.local> <1518448469.13433.104.camel@nic.cz> <20180212172936.lt2stijpxgk6o3ug@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 12 Feb 2018 11:44:41 -0800
Message-ID: <CABCOCHQNSOUJQWodKvJkd9BYB_9dJOweD+2YDo+aO9DjEtVQOg@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1cfa4a0035cf0565091c22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rUU91a7hpFH8azrD3pKJkhyOFdA>
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
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: Mon, 12 Feb 2018 19:44:47 -0000
On Mon, Feb 12, 2018 at 9:29 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote: > > On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote: > > > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote: > > > > > > > > > **** Sec. 1 - YANG library stability > > > > > > > > > > > > The text basically says that the YANG library information > can > > > > > > change at any time. This has been recently discussed but I > > > > > > haven't seen any conclusion yet. I understand it is > difficult to > > > > > > enumerate all the situations when this information can > change, > > > > > > but it should also be emphasized that YL info is not just > another > > > > > > subtree of state data and that it should not change > haphazardly. > > > > > > > > > > I agree, but I think that YANG library's job is to report what the > > > > > server implements. If the server dynamically changes its set of > > > > > loaded modules, then YL should adapt. > > > > > > > > > > I welcome more discussion on this topic, but I don't think it has > to > > > > > be documented in this draft. > > > > > > > > What about this? > > > > > > > > OLD > > > > The YANG library information can be different on every server and > it > > > > can change at runtime or across a server reboot. If a server > > > > implements multiple network management protocols to access the > > > > server's datastores, then each such protocol may have its own > > > > conceptual instantiation of the YANG library. > > > > > > > > NEW > > > > The YANG library information represents a management API for a > given > > > > server, > > > > and should therefore be as stable as possible. The circumstances > under > > > > which > > > > this information can change are outside the scope of this > document but it > > > > is > > > > advisable to consider potential impact on clients. > > > > > > I like the old text because it tells the client clearly that this data > > > can change. And the statement has been in RFC 7895 in the exact same > > > > My problem with the current text is that it seems to make no difference > between > > YANG library and any other state data. > > The sentence starts with 'The YANG library information' and what > follows is all scoped to 'YANG library information'. > > > > wording. If you want to add a statement that servers should not change > > > the YANG library without reason I could live with that but any attempt > > > to write text that makes the server somewhat guilty when a client is > > > > Not guilty but careful. There is no requirement that clients check YANG > library > > between every two operations, and notifications are optional. > > > So let me try to make an alternate proposal. (I only added the second > sentence.) > > NEW: > > The YANG library information can be different on every server and > it can change at runtime or across a server reboot. Servers may > schedule YANG library changes in way that minimizes the impact on > active clients. If a server implements multiple network management > protocols to access the server's datastores, then each such > protocol may have its own conceptual instantiation of the YANG > library. > > > > not prepared to handle a YANG library change is IMHO a fundamental > > > change from what RFC 7895 said. > > > > > > > > > It is like with database schemas, REST APIs and the like. Of > > > > > > course, these can change as well, but everybody has to > understand > > > > > > that doing so means transition problems, broken clients etc. > > > > > > > > > > > > For this reason, it might be useful to set YL and schema > mount > > > > > > data aside and call them metadata or schema information - > even if > > > > > > we continue modelling them with YANG. > > > > > > > > > > Do you have some concrete proposal for where to introduce this > term? > > > > > > > > In RESTCONF it could be a separate well-known resource outside all > > > > datastores. > > > > > > Putting the data into a different place does not change the impact of > > > the data changing. So I do not understand which problem introducing > > > yet another datastore solves. > > > > Nothing except emphasizing the difference between data and metadata, > which is > > IMO an important one. > > So its a different topic - one that we closed before I thought. > > > > > > > **** Sec. 4 - checksum > > > > > > > > > > > > I think it would be very useful (even if not immediately) to > > > > > > standardize the procedure for computing the checksum. What I > > > > > > envision are systems that construct and process YANG schemas > > > > > > (such as the YANG Catalog). They could benefit from having a > > > > > > universal hash string as a characteristic of any particular > > > > > > schema. Just consider how useful the universal hashes are > e.g. in > > > > > > git. > > > > > > > > > > Ok. It would be interesting to see such a scheme. But I agree it > is > > > > > not needed immediately for this document. > > > > > > > > Checksums are mandatory, so every implementation has to invent some > scheme. > > > > > > > > Actually, it might be useful to have checksums also on module-sets, > schemas > > > > and > > > > datastores so that the client can easily localize the changes and > retrieve > > > > again > > > > only necessary data. > > > > > > With RESTCONF, you can use etags and conditional requests. NETCONF > > > lacks a similar generic mechanism to support caching. Instead of > > > adding checksum everywhere into our data models, it seems a better > > > solution would be to add something like etags to NETCONF. Hence, we > > > reduced this to a single checksum which is needed as it is carried in > > > the hello message. > > > > Etags work, but my point here is to have the checksum as a globally > unique > > identifier of a given data model, schema or module set. For example, it > would > > allow for checking that multiple servers use the same data model. > > I was commenting on your proposal to have multiple checksums. > > Concering your other proposal, namely to specify a detailed algorithm > how to calculate these checksums, I have reservations as well but for > other reasons. First, RFC 7895 does not specify this. Second, for the > usage in the NC hello exchange, it is not necessary that there is a > common way to calculate the checksum. Third, the current definition in > RFC 7895 (which has not been changed by the update) allows efficient > implementations since the number is essentially a version number. > Fourth, I have not seen a proposal for a robust algorithm that easily > produces the exact same checksum across a number of equivalent > configurations (the root problem is that the notion YANG library > equivalence is nowhere really defined - you can't simply serialize > YANG library data and checksum the result since there are only limited > serialization ordering requirements). > > I agree that the YANG library should not mandate a checksum algorithm. I do not even like calling this field checksum (or having multiple fields). > /js > > Andy > -- > 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] LL review of draft-ietf-netconf-rfc7895b… Ladislav Lhotka
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Martin Bjorklund
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Ladislav Lhotka
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Juergen Schoenwaelder
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Ladislav Lhotka
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Juergen Schoenwaelder
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Andy Bierman
- Re: [netmod] LL review of draft-ietf-netconf-rfc7… Andy Bierman