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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod