Re: [netmod] yang-json document

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Mon, Feb 9, 2015 at 4:56 AM, Martin Bjorklund <[e-mail]> wrote:
> > Ladislav Lhotka <[e-mail]> wrote:
> >>
> >> > On 09 Feb 2015, at 09:59, Andy Bierman <[e-mail]> wrote:
> >> >
> >> > On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund <[e-mail]>
> >> > wrote:
> >> >> Phil Shafer <[e-mail]> wrote:
> >> >>> Andy Bierman writes:
> >> >>>> Solution Y34-06
> >> >>>>   - do not deprecate anyxml
> >> >>>>   - do not add anydata (no agreement on rules)
> >> >>>>   - implementations MAY restrict the XML accepted in anyxml
> >> >>>>      - MAY ignore processing instructions
> >> >>>>      - MAY reject mixed mode input
> >> >>>>   - document in YANG 1.1 that anyxml is not considered interoperable
> >> >>>>     if PIs and mixed mode XML are used
> >> >>>
> >> >>> This is essenially "be aware that server implementations might not
> >> >>> implement all of YANG".
> >> >>>
> >> >
> >> > Isn't this already the case?
> >> > Why is it that not all servers fully support anyxml?
> >> >
> >> >
> >> >>>>   - The guidelines document should say that YANG Doctors will review
> >> >>>>     each use of anyxml in IETF modules
> >> >>>
> >> >>> This part I completely agree with.
> >> >>>
> >> >>> Here's my proposal:
> >> >>>
> >> >>> Solution Y34-07
> >> >>>  - do not change YANG
> >> >>>  - Change the JSON encoding rules to encode anyxml nodes as strings
> >> >>>  - The guidelines document should say that YANG Doctors will review
> >> >>>    each use of anyxml in IETF modules (lifted from Y34-06)
> >> >>
> >> >> This is fine (*) as one part of the solution, but by itself it isn't
> >> >> sufficient.
> >> >>
> >> >> The problem is illustrated in YANG PATCH, which is supposed to work
> >> >> for both XML and JSON.  If YANG PATCH uses anyxml, it means that the
> >> >> JSON encoding of a YANG PATCH is pretty much useless (since the edit
> >> >> would be expressed as XML, but the reast in JSON).
> >> >>
> >> >> This is why we have suggested to add anydata, which YANG PATCH then
> >> >> should use instead of anyxml.
> >> >>
> >> >
> >> >
> >> > I strongly object to making YANG Patch YANG 1.1 only.
> >> > I would rather drop JSON support.
> >>
> >> I think you can continue using anyxml in YANG PATCH, IMO there is
> >> nothing wrong with it. If the module gets upgraded to YANG 1.1, the
> >> descriptions could perhaps be made shorter, and that’s all.
> >
> > I think you're missing the context.  Phil suggested that anyxml should
> > be encoded as a string in json, and we're discussing the implications
> > of that.  In this context, I do not think that anyxml can be used in
> > YANG PATCH - or we do what Andy suggests, drop json support.
> >
> 
> It would be a shame to drop JSON support, because implementations will
> ignore the standard and continue to support JSON in proprietary ways.
> 
> The frustrating part for me is that there is not 1 single implementation
> that is actually using anyxml as configuration storage for HTML.
> If this is such a great use-case, then why isn't anybody doing it?
> 
> OTOH, using anyxml as free-form YANG data nodes is implemented
> by many vendors, in many forms, and has been working fine for years.

Agreed.  But this is not anyxml, it is anydata.  So if we introduce
anydata, we're standardizing what people are doing already.

anyxml is still needed in order to correctly define the NETCONF
protocol.  There are actually quite a few NETCONF implementations that
still use some proprietary language; i.e., even if we had anydata it
would be inappropraite to use it in the ietf-netconf.yang model.

> I don't know why we would design for the 0% use-case instead of the
> 100% use-cases.  The IETF seems to get wrapped around the axle
> far too easily.

To me it seems the only issue is timing.  If we had YANG 1.1. w/
anydata today, YANG PATCH would use it, and everyone would be happy.

anydata would have a clear encoding and mapping in JSON, and anyxml
would not.


/martin