Subject: [netmod] New proposal: Yang Schema annotation

From: Balazs Lengyel <[email-masked]>
Date: Wed, 25 Jan 2017 09:51:01 +0100

Hello,

As a result of work coming from the Yangpush effort I just posted a draft
https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00

This proposes a way to extend YANG modules with extra properties for 
specific schema nodes without modifying the text of the original YANG 
module. We have a strong need for this in Yangpush, but it would be 
useful/needed outside Yangpush as well.

Please review, comment!

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jan 2017 13:41:27 +0100

Hi Balazs,

I agree that such a mechanism would be pretty useful.

I think though that the deviation-based approach can be used without
further ado. Why do you think that the "deviate" statement cannot handle
extension statements? AFAICT, the following module satisfies all rules
of RFC 7950, and it is then up to an implementation to handle the
extension, so it can also add it as an annotation to the target node.

module devext {
  namespace "http://example.com/devext";
  prefix de;
  import ietf-interfaces {
    prefix if;
  }
  extension foo;
  deviation "/if:interfaces" {
    deviate "add" {
      de:foo;
    }
  }
}

Lada

Balazs Lengyel <[email-masked]> writes:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Vinod Kumar <[email-masked]>
Date: Wed, 25 Jan 2017 20:32:55 +0530

Hi Balazs,
    Yes we do agree, that there is a need to associate additional
information with the data modeled objects, based on the use cases the kind
of information required and interpretation would vary.
     So we had defined a generic extension for annotations, as per the
below draft (which will be refreshed shortly) .
https://tools.ietf.org/html/draft-agv-netmod-yang-compiler-metadata-01
     We feel that we could have a unified generic extension, which can be
used to annotate the schema objects.
      Kindly let us know your opinion in this regard.

Thanks and Regards,
Vinod Kumar S.

On Wed, Jan 25, 2017 at 2:21 PM, Balazs Lengyel <[email-masked]
> wrote:

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 25 Jan 2017 16:13:55 +0100

Hello Lada,

Thanks for the support, I would like to get this in as a
workgroup document soon.

Deviations are conceptually used to define ugly limitations. The
yang-push group agreed it would be a misuse of deviations to use
them for something constructive, like adding new schema
information.

Also chapter https://tools.ietf.org/html/rfc7950#section-14
explicitly lists the statements allowed in deviations e.g.

deviate-add-stmt = deviate-keyword sep add-keyword-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[units-stmt]
*must-stmt
*unique-stmt
*default-stmt
[config-stmt]
[mandatory-stmt]
[min-elements-stmt]
[max-elements-stmt]
"}") stmtsep

This excludes the extension statement. :-(  So adding extensions
by deviations would modify RFC7950.

My pyang did not accept devext.yang.

(Side-note: there are other statements that should be but are not
allowed by deviations like description, status, identity, enum
etc. )

regards Balazs

On 2017-01-25 13:41, Ladislav Lhotka
wrote:

Hi Balazs,

module devext {

Lada

Hello,

Please review, comment!

regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jan 2017 16:29:31 +0100

> On 25 Jan 2017, at 16:13, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello Lada,
> 
> Thanks for the support, I would like to get this in as a workgroup document soon.
> 
> Deviations are conceptually used to define ugly limitations. The yang-push group agreed it would be a misuse of deviations to use them for something constructive, like adding new schema information.

I don't think this is a big problem. Another similar and simple solution might be to permit "augment" with no substatements - it cannot IMO cause any harm. And then extensions could be piggybacked in it.

> 
> Also chapter https://tools.ietf.org/html/rfc7950#section-14 explicitly lists the statements allowed in deviations e.g. 
> This excludes the extension statement. :-(  So adding extensions by deviations would modify RFC7950.

Actually, no, extension statement can be derived form the "stmtsep" non-terminal:

   stmtsep             = *(WSP / line-break / unknown-statement)

   ;; represents the usage of an extension
   unknown-statement   = prefix ":" identifier [sep string] optsep
                         (";" /
                          "{" optsep
                              *((yang-stmt / unknown-statement) optsep)
                           "}") stmtsep

> My pyang did not accept devext.yang.

Yes, I know, it probably even crashed:

https://github.com/mbj4668/pyang/issues/300

> (Side-note: there are other statements that should be but are not allowed by deviations like description, status, identity, enum etc. )

Yes, this was already discussed.

Lada

> regards Balazs
> 
> On 2017-01-25 13:41, Ladislav Lhotka wrote:
>> Hi Balazs,
>> 
>>   namespace 
>> "http://example.com/devext"
>> ;
>>   prefix de;
>>   import ietf-interfaces {
>>     prefix if;
>>   }
>>   extension foo;
>> Balazs Lengyel 
>> <[email-masked]>
>>  writes:
>> 
>> 
>>> Hello,
>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Jan 2017 16:40:40 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> > yang-push group agreed it would be a misuse of deviations to use them
> > for something constructive, like adding new schema information.
> 
> I don't think this is a big problem. Another similar and simple
> solution might be to permit "augment" with no substatements - it
> cannot IMO cause any harm. And then extensions could be piggybacked in
> it.
> 
> > 
> > Also chapter https://tools.ietf.org/html/rfc7950#section-14 explicitly
> > lists the statements allowed in deviations e.g.

Furthermore, RFC 7950, section 7.20.3.2 says:

   If the target node has a property defined by an extension, this
   property can be deviated if the extension allows deviations.  See
   Section 7.19 for details.

and 7.19 says:

   An extension can allow refinement (see Section 7.13.2) and deviations
   (Section 7.20.3.2), but the mechanism for how this is defined is
   outside the scope of this specification.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 25 Jan 2017 16:42:32 +0100

I see a problem.

This, as I read it, does not allow for an argument. Am I misreading it or is this an error ???
Balazs

On 2017-01-25 16:29, Ladislav Lhotka
wrote:

Hello Lada,

Lada

regards Balazs

Hi Balazs,

module devext {
namespace

Lada

Balazs Lengyel

Hello,

Please review, comment!

regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email:
[email-masked]

[email-masked]

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email:
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jan 2017 07:50:29 -0800

> extension, so it can also add it as an annotation to the target node.

We fully implement the use of deviations in this manner.
We even call a deviation module that is not supposed to be advertised
as an annotation.

I agree that YANG 1.1 supports this use of deviations.

Andy