Re: Gen-Art LC review: draft-ietf-netmod-yang-metadata-04
Ladislav Lhotka <lhotka@nic.cz> Fri, 11 March 2016 12:58 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062F212D6CB; Fri, 11 Mar 2016 04:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 KPjS8CG-7q55; Fri, 11 Mar 2016 04:58:26 -0800 (PST)
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 75AF912D6C6; Fri, 11 Mar 2016 04:58:26 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15] (unknown [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15]) by mail.nic.cz (Postfix) with ESMTPSA id A4704181B37; Fri, 11 Mar 2016 13:58:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457701104; bh=i/zFx6awqT/lZnLatdRdXQZRg2OdECEY277GphGOpUw=; h=From:Date:To; b=Lfo47cHxkwSXnGT0EE4T3zNZbKFDZQ4BvQe7aV07gBORq232qesJ6RjoJleORIcJo ttl6yFDvYFMYYKjg9kUzUCj1dFaT54xsqCPh3G+3l8vj/64BDDzBVDwuGkYunwoVQN LBD0Vie8hiMVEPYtxBvTeR8GyzMpO+VLaqO12GTM=
Subject: Re: Gen-Art LC review: draft-ietf-netmod-yang-metadata-04
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset="windows-1252"
From: Ladislav Lhotka <lhotka@nic.cz>
X-Priority: 3
In-Reply-To: <033701d17b91$710ce580$4001a8c0@gateway.2wire.net>
Date: Fri, 11 Mar 2016 13:58:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <52538EAC-7C3D-4EEF-8E78-F202FB68CB2A@nic.cz>
References: <56D60EF5.7020001@nostrum.com> <m27fhbvb07.fsf@birdie.labs.nic.cz> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net>
To: "tom p." <daedulus@btconnect.com>
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/LaPnjsV3x-TJ8SAmlkOOZryaKnk>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-netmod-yang-metadata.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2016 12:58:29 -0000
> On 11 Mar 2016, at 12:15, tom p. <daedulus@btconnect.com> wrote: > > Lada, Robert > > The other angle from which this might be approached is that the I-D > already says > > " Using the "type" statement, a type is specified for the annotation > value according to the same rules as for YANG "leaf" type. " > > while rfc6020bis says > > " The "leaf" statement is used to define a scalar variable of a > particular built-in or derived type." > > so if you know your YANG off by heart, then you will know that > annotations must be scalar. I agree that the text needs to be clearer. > Perhaps, > OLD > " o annotations are scalar values and cannot be further structured;" > NEW > "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis This is again confusing, "leaf" is a data node, not type. But even then, there are some things that may be defined for leafs but not for annotations, such as a default value or "must" expression. As you rightly said, 6020(bis) is quite clear: types only pertain to scalar values. I believe the problem is in carrying over the meaning that "type" has in programming languages (array or struct type) to YANG. Lada > s.7.6] and so are limited to scalar variables." > > Tom Petch > > ----- Original Message ----- > From: "Ladislav Lhotka" <lhotka@nic.cz> > To: "Robert Sparks" <rjsparks@nostrum.com> > Cc: "General Area Review Team" <gen-art@ietf.org>; <ietf@ietf.org>; > <netmod@ietf.org>; <draft-ietf-netmod-yang-metadata.all@ietf.org> > Sent: Friday, March 11, 2016 9:32 AM > >> On 11 Mar 2016, at 00:57, Robert Sparks <rjsparks@nostrum.com> wrote: >> >> >> >> On 3/9/16 11:04 AM, Ladislav Lhotka wrote: >>> Hi Robert, >>> >>> thanks for the review, I apologize for replying late, please see my > responses inline: >>> >>> Robert Sparks <rjsparks@nostrum.com> writes: >>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-netmod-yang-metadata-04 >>>> Reviewer: Robert Sparks >>>> Review Date: 1Mar2016 >>>> IETF LC End Date: 9Mar2016 >>>> IESG Telechat date: not yet scheduled >>>> >>>> Summary: Ready with nits >>>> >>>> 1) I might be missing something obvious, but the introduction has > two >>>> statements that don't seem aligned: >>>> >>>> " Values of annotations are not limited to strings; any YANG > built-in or >>>> derived type may be used for them" >>>> and >>>> "annotations are scalar values and cannot be further structured". >>> These two statements are not in conflict: YANG data types (built-in > or >>> derived) apply to scalar values. >> I don't know what it means for a data type to apply to a value. Can > you say that more simply? > > Every leaf node definition must define the leaf's type - built-in or > derived. Annotations can use exactly the same types. YANG types are > analogical to what "datatype" means in W3C XML Schema or RELAX NG - it > represents constraints for a *scalar* value (or text in XML terms). I > think you are confusing categories of YANG data nodes (leaf, container, > list, leaf-list, anyxml, anydata) with types (string, boolean, int8, > etc.). > >> >> I think this is just a language thing, and being precise in the text > will get past it. > > The Terminology section now refers to definitions of "built-in type" and > "derived type" in draft-ietf-netmod-rfc6020bis, and the latter document > is a normative reference. So understanding these terms is a prerequisite > for the present document. In my view, the formulations are quite > precise, but I am open to suggestions for improvements. > >> >> Are you saying all YANG data types (built-in or derived) have only > scalar values? > > No, data types represent constraints on scalar values. > >> >> If so, you could change the second point in the document to say >> "Since annotations have only built-in or derived types, they can only > have scalar values." >> >> But then, placing the point under "This document deliberately adopts > some restrictions" doesn't make sense, and I suggest restructuring the > discussion to only call out the restrictions (which appears to be to not > place annotations on lists or leaf-lists) below that sentence. > > The logic is this: it would be trivial to extend the mechanism of this > document to allow for annotations being arbitrarily complex data trees > with containers, lists, etc. It is also not difficult to imagine use > cases where it would come handy. However, the WG consensus was that at > his time we don't want to give up the convenience of XML attributes in > the XML encoding, and that's why we adopted extra restrictions that > mirror the restrictions of XML attributes. I believe the text in the > Introduction captures this quite well: > > In the XML encoding, XML attributes are a natural instrument for > attaching annotations to data node instances. This document > deliberately adopts some restrictions in order to remain compatible > with the XML encoding of YANG data node instances and limitations of > XML attributes. Specifically, > > o annotations are scalar values and cannot be further structured; > > o annotations cannot be attached to a whole list or leaf-list > instance, only to individual list or leaf-list entries. > > If it turns out that structured annotations are needed, another document > (or an update to this one) can introduce them, including appropriate XML > encoding rules. > > Thanks, Lada > >> >> >>> >>>> If I'm not missing something, that may be more of an open issue than > a nit. >>>> >>>> 2) The shepherd writeup calls out the tension in figuring out > whether to >>>> make this an extension or a new built-in statement. Please consider >>>> capturing the reasoning for the path you chose in the draft itself. >>> I will try, the main reason was that most people felt that > introducing a >>> new built-in statement is too big a change for the upcoming > maintenance >>> version of YANG (1.1) and YANG 2.0 is nowhere in sight. >>> >>> Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- Gen-Art LC review: draft-ietf-netmod-yang-metadat… Robert Sparks
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Ladislav Lhotka
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Robert Sparks
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Ladislav Lhotka
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… tom p.
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Ladislav Lhotka
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Juergen Schoenwaelder
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Ladislav Lhotka
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Robert Sparks
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… tom p.
- Re: Gen-Art LC review: draft-ietf-netmod-yang-met… Juergen Schoenwaelder
- Re: [Gen-art] Gen-Art LC review: draft-ietf-netmo… Jari Arkko