Subject: [netmod] undecided Y33 add 'attribute' statement

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jun 2014 10:24:21 +0200

We need to decide whether this is in scope of YANG 1.1 or not.

Is there a risk of attributes getting abused? How do we define
metadata? We do not seem to want people to use attributes to model
data.

/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, 03 Jun 2014 15:10:03 +0200

> metadata? We do not seem to want people to use attributes to model

Yes, this has to be discussed. The secondary point of this issue is that IF any standard (global) attributes are to be defined, YANG modules are a good place to do it, rather than, say, using new NETCONF capabilities.

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Jun 2014 08:26:11 -0700

On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka <[email-masked]> wrote:

> Yes, this has to be discussed. The secondary point of this issue is that
> IF any standard (global) attributes are to be defined, YANG modules are a
> good place to do it, rather than, say, using new NETCONF capabilities.
>
>
OK to discuss, the problem to solve is poorly specified.  IMO there can be
no
attributes in the data model. None. Zero.  But a peer implementing
the NETCONF or RESTCONF protocol MAY inject attributes into messages to
the other peer.

For RESTCONF+json a YANG module name is needed to identify the extended
name part of a qualified attribute. For NC/RC+xml, an XML namespace is
needed instead.

If a designer is intent on using attributes in the data model, then they
will abuse
the attribute-stmt.  IMO this is a problem for the YANG Guidelines RFC, not
YANG 1.1.
Such attributes could be quite useful to convert a legacy/proprietary DML
to YANG.
If the existing code expects a certain XML blob to perform its function,
then modeling
that blob correctly in YANG could be the only migration path (e.g.
funding/time to rewrite
all the legacy instrumentation at once may not be feasible).

Lada
Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 3 Jun 2014 18:45:51 +0000

Can we enumerate everywhere attributes are desired?  I only know of two:
    - those defined to support "with-defaults"
    - those defined to support "conditional-enablement"

The first was added via an RFC6253 and the second being discussed as added via an RFC6241bis.  In neither case is having YANG support needed.  If we can conclude the same for other uses, then I'd vote to close this issue.

Thanks,
Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 3, 2014 at 11:26 AM
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] undecided Y33 add 'attribute' statement

On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

OK to discuss, the problem to solve is poorly specified.  IMO there can be no
attributes in the data model. None. Zero.  But a peer implementing
the NETCONF or RESTCONF protocol MAY inject attributes into messages to
the other peer.

For RESTCONF+json a YANG module name is needed to identify the extended
name part of a qualified attribute. For NC/RC+xml, an XML namespace is needed instead.

If a designer is intent on using attributes in the data model, then they will abuse
the attribute-stmt.  IMO this is a problem for the YANG Guidelines RFC, not YANG 1.1.
Such attributes could be quite useful to convert a legacy/proprietary DML to YANG.
If the existing code expects a certain XML blob to perform its function, then modeling
that blob correctly in YANG could be the only migration path (e.g. funding/time to rewrite
all the legacy instrumentation at once may not be feasible).

Lada

Andy

> [email-masked]<mailto:[email-masked]>

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 3 Jun 2014 20:51:41 +0200

> the NETCONF or RESTCONF protocol MAY inject attributes into messages to

Agreed, that’s why the proposed solution permits the attribute statement only at the top level of a module, exactly as e.g. identities or extensions. I actually assume modules containing these attribute definitions would normally contain nothing else.

> name part of a qualified attribute. For NC/RC+xml, an XML namespace is needed instead.

Yes, that would be one of the benefits of having it in a module that both namespace identifiers would be automatically defined. Another option that’s not mentioned in the issue text is that attribute definitions could contain datatypes.
 
> the attribute-stmt.  IMO this is a problem for the YANG Guidelines RFC, not YANG 1.1.

This issue is really about *global* attributes that can be used anywhere, which essentially implies they have to convey metadata and not plain config or state data.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:22:05 +0200

> metadata? We do not seem to want people to use attributes to model

Interim proposal:

   Proposal: Reject this issue.

If you disagree, please speak up by June 18th.

/js