Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes:

> On Wed, Sep 16, 2015 at 08:29:16PM +0200, Ladislav Lhotka wrote:
>> 
>> > On 16 Sep 2015, at 18:00, Andy Bierman <a...@yumaworks.com> wrote:
>> > 
>> > 
>> > 
>> > On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder 
>> > <j.schoenwael...@jacobs-university.de> wrote:
>> > On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
>> > > On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
>> > > randy_pres...@mindspring.com> wrote:
>> > >
>> > > > Hi -
>> > > >
>> > > > >From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
>> > > > >Sent: Sep 14, 2015 11:41 PM
>> > > > >To: Ladislav Lhotka <lho...@nic.cz>
>> > > > >Cc: NETMOD Working Group <netmod@ietf.org>
>> > > > >Subject: Re: [netmod] Fwd: New Version Notification for
>> > > > draft-ietf-netmod-yang-json-05.txt
>> > > > ...
>> > > > >My question is why the text is silent about the case where the data
>> > > > >model is present. Should it not say that if the data model is present,
>> > > > >the data encoded inside the anydata node must follow the rules of this
>> > > > >document? Perhaps this is the implicit assumption but I think it will
>> > > > >be useful to say this explicitly (if we agree on this).
>> > > > >
>> > > > >If the data model is not present, then I think an implementation is
>> > > > >still expected to produce an encoding that follows the rules of this
>> > > > >document as much as possible except that things that requires data
>> > > > >model knowledge may be encoded differently (e.g., numbers appearing as
>> > > > >strings or namespace names being different). I am thinking along the
>> > > > >lines of this proposed new text:
>> > > > >
>> > > > >   An anydata data node can contain an unknown set of nodes that can
>> > > > >   be modelled by YANG. A data model for anydata content may or may
>> > > > >   not exist at run time.  If the data model for anydata content is
>> > > > >   available, then the anydata content MUST be encoded according to
>> > > > >   the rules of this specification. If the data model for anydata
>> > > > >   content is not available, the encoding MUST follow the rules of
>> > > > >   this specification except for rules that require data model
>> > > > >   knowledge (and as a consequence, numbers may appear as strings or
>> > > > >   namespace qualifiers may not match module names).
>> > > >
>> > > > This leaves me wondering what it means for the data model for
>> > > > anydata content to be "available".  In the case of ASN.1's
>> > > > "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
>> > > > unambiguously identify the grammar (and associated semantics)
>> > > > to be used to understand the content, so tools can, if needed,
>> > > > scurry off to obtain the parsing instructions for those
>> > > > particular bits.  How does an implementation know in the case
>> > > > of "anydata" which datamodel to use?
>> > > >
>> > > >
>> > > Good questions....
>> > > The text "If the data model for anydata content is available" gives a 
>> > > hint
>> > > of just
>> > > what a hack anydata is in YANG.  The definition of anydata is that there 
>> > > is
>> > > no data model for the specified subtree.  The mere mention of an 
>> > > out-of-band
>> > > data mode is inappropriate and confusing.
>> > >
>> > > I understand this is intended to support usage like in YANG Patch, where 
>> > > the
>> > > description-stmt of 'value' says that the child node must follow the 
>> > > schema
>> > > for the node in the target leaf.  More hacks to get YANG to work.
>> > 
>> > You are welcome to provide fixes.
>> > 
>> > 
>> > OLD:
>> > 
>> > 
>> >   An anydata data node can contain an unknown set of nodes that can
>> >   be modelled by YANG. A data model for anydata content may or may
>> >    not exist at run time.  If the data model for anydata content is
>> >    available, then the anydata content MUST be encoded according to
>> >   the rules of this specification. If the data model for anydata
>> >   content is not available, the encoding MUST follow the rules of
>> >   this specification except for rules that require data model
>> >    knowledge (and as a consequence, numbers may appear as strings or
>> >   namespace qualifiers may not match module names).
>> > 
>> > 
>> > NEW:
>> > 
>> >   An anydata data node can contain an unknown set of nodes that can
>> >   be modelled by YANG.
>> 
>> This text is essentially in 6020bis, I see no need to repeat it. 
>> 
>> >  
>> > 
>> >  The YANG RFC itself should be silent about data-model specific
>> > semantics that are added to an anydata subtree.  The text "if available"
>> > is especially non-enforceable and therefore pointless.
>> > 
>> 
>> I must admit I am getting lost in these discussions. It seems to me there is 
>> a lot of hand-waving and hidden assumptions that moreover differ from one 
>> person to another. As I already said in Prague, both anyxml and anydata are 
>> IMO constructs of marginal utility and it is frustrating we spend so much 
>> effort on them.
>>
>
> I agree that anyxml is of marginal utility, anydata however is needed
> for any rpc/action/notification or future language construct that can
> work with generic YANG content and hence I think its behaviour and
> encoding should be well defined.

But then I believe we should have stricter rules for anydata than just
"an unknown set of nodes that can be modelled with YANG" - it should be
stated that the data model for an anydata instance MUST be known at
run-time. Otherwise I think anyxml can cover all use cases you mention
as well (as it has done in the past), and there is no need to introduce
a new data node type with a definition that allows for multiple
interpretations.

Lada

>
> /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/>

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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to