Re: [netmod] metadata in JSON

[Ladislav Lhotka <[e-mail]>]

On 28 Jul 2014, at 16:54, Andy Bierman <[e-mail]> wrote:

> 
> 
> 
> On Mon, Jul 28, 2014 at 7:17 AM, Ladislav Lhotka <[e-mail]> wrote:
> 
> On 28 Jul 2014, at 15:32, Andy Bierman <[e-mail]> wrote:
> 
> >
> >
> >
> > On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka <[e-mail]> wrote:
> >
> > On 28 Jul 2014, at 14:33, Andy Bierman <[e-mail]> wrote:
> >
> > >
> > >
> > >
> > > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> > > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote:
> > > >
> > >
> > > > But then, IMO, the cleanest way is to make this explicit by using the “attribute” statement which
> > > >
> > > > - assigns the attribute to a module,
> > > > - also assigns the namespace URI and recommended prefix for XML encoding,
> > > > - defines a datatype for the attribute, which may occasionally be useful.
> > > >
> > > > I’d like to emphasize that Y33 was only about global attributes, i.e. it doesn’t attempt to make attributes into regular data nodes, so the following would NOT be possible:
> > > >
> > > > leaf flag {
> > > >     attribute foo {…}
> > > >     …
> > > > }
> > >
> > > I can counter argue that easily: If we do not do Y33, then there are
> > > no attributes and hence there is no need to encode them in JSON. Move
> > > the whole attribute encoding text into a non-normative appendix and we
> > > are done.
> > >
> > >
> > > Several people want to support attributes in the RESTCONF protocol messages.
> > > Martin came up with a solution that works and we already agreed to use it
> > > in RESTCONF.
> >
> > This doesn’t necessarily mean it has to be part of draft-ietf-netmod-yang-json.
> >
> 
> 
> So if it was moved to a different document, that would be OK?
> Vendors will implement the standard if there is one.  If not,
> the features vendors need will get implemented anyway,
> but proprietary schemes.

As far as the yang-json draft is concerned, this would be OK. Attributes aren’t YANG data nodes.

> 
> >
> >

...

> > The WG already decided to move this text from RESTCONF to the JSON draft.
> 
> I haven’t seen any evidence of this being a WG decision. That’s why the first question in my presentation in Toronto was
> 
>    Is this draft an appropriate place for defining metadata encoding in JSON?
> 
> and I didn’t notice any consensus about this in the room. In the relevant thread
> 
> http://www.ietf.org/mail-archive/web/netmod/current/msg09338.html
> 
> only you and Martin wanted to have the mapping in the yang-json draft but Martin also said (http://www.ietf.org/mail-archive/web/netmod/current/msg09350.html):
> 
>        Maybe the original JSON mapping idea is the only one that works; i.e.,
>        map pure YANG data to JSON.  No meta data.  A protocol that needs meta
>        data should not use JSON; use XML instead.
> 
> 
> > So what new arguments are you presenting that justify re-opening this issue?
> 
> The lack of namespace mapping.
> 
> 
> The RFC that defines any protocol attributes for RESTCONF can define a YANG module
> if they want, so there is a module name to specify in the ad-hoc or XSD text. 
> 
> RFC 6020bis can easily register a standard module name
> that goes with the YANG XML namespace if the insert attributes
> ever need to be supported (and there is desire to make sure YANG
> is not XML-specific).  Your draft just needs to say
> that the field contains a YANG module name.

It should also specify how the association between an attribute and a module is established, if the module says nothing about it, or even doesn’t exist at all. How do you find out which attributes are associated with a given module? Can anybody add a new attribute to an existing module at any time? 

I really fail to see how a module-top-level “attribute” statement could possibly encourage misuse of attributes, I’d say it’s rather the opposite. Having an explicit attribute definition with a description and subject to revision rules of YANG modules etc. is IMO much better than implicit and hand-waving associations.

Lada

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