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

From: Kent Watsen <[email-masked]>
Date: Tue, 6 Jan 2015 01:11:40 +0000

Hi Lada,

I don't understand the need for a module like this.  I fully appreciate us
wanting annotations (default, enabled, etc.), but see those as better
defined in purpose-specific drafts (e.g., 'default' is defined in RFC
6243).  Also, consider that some annotations might require additional
interactions to work (report-all-tagged) whereas others would require
versioning the protocol, so clients that don't understand the annotations
don't break things, though we might get away with having a general
requirement that clients MUST echo all annotations verbatim in case they
don't understand them (like on the <rpc> and <rpc-reply> elements)

It seems that your primary motivation is to have a "type" annotation to
support JSON parsing.  I understand that need - it reminds me of the XML
schema instance "type" annotation, used to support types derived off a
base type.  But why not define a specific draft for it instead?

As for the "enabled" attribute (that's what I called it), I am hoping to
resurrect that conversation after current drafts are out the door.  Having
different names for each variant of a boolean expression won't work, since
there will be contradictions and/or ambiguities.  For instance, consider
this:

	<foobar enabled=false enabled-between="9am-to-5pm"
enabled-if="/sys/cpu-usage >= 90%">

Kent

On 12/2/14, 5:17 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>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-annotation
>>>>s-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
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Jan 2015 12:57:37 +0100

Hi Kent,

> 6243).  Also, consider that some annotations might require additional

I thought these annotations (and maybe some more) might be of general
interest, which was apparently a mistake.

> support JSON parsing.  I understand that need - it reminds me of the

Actually, this one would be slightly more useful for XML. My motivation
however was to overcome the limitations of the existing union rules and
make unions easier to resolve. For example, up to three regexps have to
be matched in order to resolve an inet:host value.

> XML schema instance "type" annotation, used to support types derived
> off a base type.  But why not define a specific draft for it instead?
>
> resurrect that conversation after current drafts are out the door.

Sure.

> Having different names for each variant of a boolean expression won't work, since

It is easy to define reasonable arbitration rules, e.g. enabled="false"
would take precedence in this case. Occassionally, it can be useful to
be able to do something like in your example.

Also, I thought enabled="false" was a no-brainer whereas enabled-if
will probably need much longer discussion.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jan 2015 13:09:34 +0100

> be matched in order to resolve an inet:host value.

Implementors have said that there is no problem. There is no
requirement to implement things in the most inefficient way. There are
of course more efficient ways to convert an inet:host value into an
internal representation. Having a common type library allows to
implement and utilize such optimizations.

You seem to believe that type information on the wire is a good
thing. I am not sure this view is generally shared. I have heard from
implementors that they will follow the postel principle and be lenient
in what they accept (that is they may even ignore the type information
of a particular encoding for the sake of interoperability). YANG was
not designed to carry type information on the wire. And as far as I
recall, this was by intention. The fact that some ecodings may carry
type information should not change the design of YANG. And we already
learned that type systems sometimes do not align well anyway.

/js

-- 
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, 6 Jan 2015 14:16:55 +0100

Juergen,

as I already said, I consider that draft dead and I am not going to defend this annotation or another. I just tried to explain my original motivation because Kent wrote that it was intended to aid JSON parsing, which it wasn’t.

Lada

> On 06 Jan 2015, at 13:09, Juergen Schoenwaelder <[email-masked]> wrote:
>