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>rg>; <ietf@ietf.org>rg>;
> <netmod@ietf.org>rg>; <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