Hi Alexander, thank you for reviewing the document.
Alexander Kolchinsky <[email protected]> writes: > 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 > } > } No, the "top" container is defined in "foomod" and thus belongs to its namespace. > > 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>"; > There have already been several ultra-long discussions about this in the NETMOD mailing list. The stance taken by this draft is that anyxml is just some data for which the schema is not known (in advance), or the schema is not YANG. The only requirement is that the document containing anyxml instance must remain valid for the given encoding. So JSON string may also be anyxml content but it's not limited to that. I believe this is a natural extension of the purpose that anyxml played when XML was the only encoding, and it can be used in the same way for other encodings that may be defined in the future, such as CBOR. The only problem, for me at least, is that it is a misnomer. > > 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) This can be achieved using a choice. > > > > Comment #3: > > > It would be better to provide examples for sections 6.2-6.7 OK, I will add some. > > > 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. No, the identity "ethernetCsmacd" is defined in the "iana-if-type" module and belongs to its namespace, so "iana-if-type:ethernetCsmacd" is correct. https://tools.ietf.org/html/rfc7224#section-2 > > 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? If the string is syntactically correct uint64, it will be classified as such, otherwise it will be plain string. > > Seems like it would be more reliable to have a union selector: > > > "bar" { > > "union-selector": "uint64", > > "value": "99999999.99999" > > } I agree, but it is a deficiency of YANG union in general. I tried to propose the "type" annotation for this purpose: https://tools.ietf.org/html/draft-lhotka-netmod-yang-annotations-00#section-3.2 However, this idea didn't receive any support in the WG. Thanks, Lada > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
