Re: Gen-Art LC review: draft-ietf-netmod-yang-metadata-04

Ladislav Lhotka <> Fri, 11 March 2016 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 062F212D6CB; Fri, 11 Mar 2016 04:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KPjS8CG-7q55; Fri, 11 Mar 2016 04:58:26 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (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 (Postfix) with ESMTPSA id A4704181B37; Fri, 11 Mar 2016 13:58:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>
X-Priority: 3
In-Reply-To: <033701d17b91$710ce580$>
Date: Fri, 11 Mar 2016 13:58:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <033701d17b91$710ce580$>
To: "tom p." <>
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <>
Cc: General Area Review Team <>,,,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Mar 2016 12:58:29 -0000

> On 11 Mar 2016, at 12:15, tom p. <> 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,
> "   o  annotations are scalar values and cannot be further structured;"
> "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.


> s.7.6] and so are limited to scalar variables."
> Tom Petch
> ----- Original Message -----
> From: "Ladislav Lhotka" <>
> To: "Robert Sparks" <>
> Cc: "General Area Review Team" <>rg>; <>rg>;
> <>rg>; <>
> Sent: Friday, March 11, 2016 9:32 AM
>> On 11 Mar 2016, at 00:57, Robert Sparks <> 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 <> 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
>>>> <>.
>>>> 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