Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

From: Randy Presuhn <[email-masked]>
Date: Wed, 16 Sep 2015 12:01:21 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Sep 16, 2015 8:14 AM
>To: Randy Presuhn <[email-masked]>
>Cc: NETMOD Working Group <[email-masked]>
>Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
... 
>> 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?
>
>There are situations where we need ANY and not ANY DEFINED BY. Generic
>RPCs sometimes work on arbitrary data models. I think ASN.1 allows
>ANY as well.

The "naked ANY" construct was removed from ASN.1 in the last
decade of the previous century.  It caused too many problems
for parsers, especially for some non-BER transfer syntaxes.
(Akin to some of the JSON challenges we've seen here.)  The
ASN.1 world has been chugging happily along without it, AFAICT.

The "ANY DEFINED BY" construct was replaced by the "object
class field type".  See ISO/IEC 8824-1:2003 section 3.6.51
(especially the three notes) and ISO/IEC 8824-2:2003 section 14.
Although the bits on the wire remain the same, the notation is
quite different.

Randy