Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 02 Dec 2014 11:17:14 +0100

Andy Bierman <[email-masked]> writes:

> Hi,
>
> This draft defines 2 annotations: "inactive" and "type".
> I am strongly opposed to the "inactive" annotation.
> The "Conditional Enablement" draft by Kent Watsen should
> be used for this purpose.  This topic is more complicated than
> just defining an "inactive" flag.

The "inactive" annotation is Kent's "simple expression". The other
expression types (complex, time) could be added but I'd strongly suggest
to use a specific name for each.

It might be a good idea though to add if-feature as an optional
substatement of the "annotation" statement.

>
> The "type" annotation seems useless because the YANG parser
> decides what internal type gets assigned to a union.
> Sending the types inside the instance document is normally
> only done if there is no schema.

Some encoding formats (JSON in the first place) carry partial type info,
and this annotation allows both clients and servers to specify the exact
type of a union value in all encodings.

It would be immediately useful e.g. for inet:host type because the
other party then needn't match the value against multiple regexps to
figure out whether it is an IPv4, IPv6 address or a domain name.

Do you have other annotations that could be of general interest?

Lada

>
>
>
> Andy
>
>
>
> On Fri, Nov 28, 2014 at 5:36 AM, Ladislav Lhotka <[email-masked]> wrote:
>> Hi,
>>
>> this draft contains the module “ietf-yang-annotations” that is intended to contain definitions of generally useful metadata annotations. I included two annotations that I think might be handy. If you know about others, please let me know.
>>
>> Thanks, Lada
>>
>> Begin forwarded message:
>>
>>> From: [email-masked]
>>> Subject: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt
>>> Date: 28 Nov 2014 14:31:57 GMT+1
>>> To: Ladislav Lhotka <[email-masked]>, "Ladislav Lhotka" <[email-masked]>
>>>
>>>
>>> A new version of I-D, draft-lhotka-netmod-yang-annotations-00.txt
>>> has been successfully submitted by Ladislav Lhotka and posted to the
>>> IETF repository.
>>>
>>> Name:         draft-lhotka-netmod-yang-annotations
>>> Revision:     00
>>> Title:                Common Metadata Annotations for Data Modelled with YANG
>>> Document date:        2014-11-28
>>> Group:                Individual Submission
>>> Pages:                9
>>> URL:            http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-annotations-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-annotations/
>>> Htmlized:       http://tools.ietf.org/html/draft-lhotka-netmod-yang-annotations-00
>>>
>>>
>>> Abstract:
>>>   This document introduces a collection of common metadata annotations
>>>   intended for use in data modeled with the YANG language.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Dec 2014 12:46:01 +0100

> figure out whether it is an IPv4, IPv6 address or a domain name.

The litmus test for any extension statements and annotations is that
clients not understanding an extension or annotation must be able to
ignore it without causing any interoperability issues. It seems we are
on slippery grounds if a type annotation tries to override the type
matching rules of RFC 6020.

/js (writing as technical contributor)

-- 
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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 2 Dec 2014 13:24:20 +0100

> On 02 Dec 2014, at 12:46, Juergen Schoenwaelder <[email-masked]> wrote:
> 

They would ignore it and use the type discrimination algorithm that’s default for a given encoding. Please give me an example how this could cause interoperability issues.

> matching rules of RFC 6020.

RFC 6020 says in sec. 9.12:

   The union built-in type represents a value that corresponds to one of
   its member types.

As I already pointed out in my review of 6020bis, the following paragraph really makes sense only for (serialised) XML data:

“When a string representing a union data type is validated, …”

A union value (in value space) needn’t be a string.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Dec 2014 13:35:21 +0100

> They would ignore it and use the type discrimination algorithm that’s default for a given encoding. Please give me an example how this could cause interoperability issues.

We discussed this before and one of the examples was a union of a
string and and int which always leads to the string interpretation in
RFC 6020.

> A union value (in value space) needn’t be a string.

So far, everything is encoded into a string. You do not like this but
this is how YANG currently works.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Dec 2014 07:26:35 -0800

> this is how YANG currently works.

IMO the union type works fine in YANG.
The tool goes through the type-stmts in order, and matches
the first one that accepts/converts the string value into the
specified YANG type.

This extension is not needed.  It also does not work for inline types
or nested unions.

  type union {
     type int32 { range 1..10; }
     type enumeration {
        enum red;
        enum green;
     }
     type union { ... }
     type string;
  }

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 2 Dec 2014 17:25:41 +0100

> On 02 Dec 2014, at 16:26, Andy Bierman <[email-masked]> wrote:
> 

Except that this may involve matching several regexp patterns before you get the result. I don’t understand how the extra information could be harmful.

>     type int32 { range 1..10; }

Yes, this may not be able to discriminate among multiple inline types but nested unions are OK: the annotation would just contain the leaf member type that’s inside the inner union.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Dec 2014 08:44:51 -0800

> Except that this may involve matching several regexp patterns before you get the result. I don’t understand how the extra information could be harmful.

So what?
The algorithm is very simple and validating types is what servers have to do.
Overriding the YANG type is not needed and not even a good thing to do.
The JSON types do not matter -- there is only 1 schema which is in the
YANG module.

Andy