My comments for reviewing:
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04
Comment #1:
Question for section 4.
Can I also use:
{
"barmod:top": {
"foo": 54,
"bar": true
}
}
If barmod extends foobar:top, then barmod:top should also be valid, no?
Comment #2:
Example: For the anyxml definition
anyxml bar;
the following is a valid JSON-encoded instance:
"bar": [true, null, true]
I would rather have:
"bar": "<? xml version=\"1.0\" ?><data><link></link></data>";
My personal experience shows that it depends on what the client wants, and it
should be controlled by the client. For example, it could be a union of
different types:
<actual-type> (this will be encoded to whatever format is being used xml/json)
anyxml (always embed xml with CDATA)
anyjson (always embed json)
anyxml-escaped (always embed xml escaped - no CDATA)
Comment #3:
It would be better to provide examples for sections 6.2-6.7
Comment #4:
For section 6.8, it should be:
"type": "ietf-interfaces:ethernetCsmacd"
Not:
"type": "iana-if-type:ethernetCsmacd"
Because, the prefix is if, not ianaift.
Comment #5:
For section 6.10:
What if we have:
leaf bar {
type union {
type uint64;
type string;
}
}
Then how can we determine which union this string refers to?
Seems like it would be more reliable to have a union selector:
"bar" {
"union-selector": "uint64",
"value": "99999999.99999"
}
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
