On Tue, 2018-10-09 at 12:19 +0100, Robert Wilton wrote: > +1 to Martin's comments. I think that I made similar comments at the > mic at IETF 102.
Me too, it is also recoreded in the minutes. I thought this could be addressed after this draft becomes a WG item. Lada > > I strongly support the idea of documenting YANG instance data. If the WG > timing works out I would like this to cover CBOR as well. > > I also strongly support the idea of documenting server capabilities. > But I'm opposed to conflating these two separate concerns in the same draft. > > I also think that that there should be a optional mechanism to embed the > list of module revisions (and perhaps features) that are required to > correctly decode the instance data. > > E.g., the example in section 3 contains YANG library data, but I don't > know which version or YANG library I need to read in the instance data. > It might have been constructed assuming the format from RFC 7895, or it > might have been constructed using the format from YANG library bis, > which could easily fail if my tool attempts to interpret the instance > data against the schema in RFC 7895. So I think that this information > is critical for tools to be able to interpret the instance data in a > reliable fashion. > > Thanks, > Rob > > > On 09/10/2018 11:58, Martin Bjorklund wrote: > > Hi, > > > > I still think that this draft should either be split into two, one for > > specifiying the generic file format (ok with examples), and one for > > "Documenting Server Capabilities", or the document should just be > > about the file format (+ *examples*). > > > > [The current document mixes the two; it's a bit as if we had "The > > YANG language and a model for interfaces" as one doc...] > > > > It is clear that the document specifies a file format for YANG > > instance data, which is good. But it is not clear if the document > > intends to specify how a server should document its capabilities. > > > > The Introduction mainly talks about why it is important to document > > server capabilities. But then AFAICT there is no normative > > specification of how a server would document its capabilities. > > > > > > /martin > > > > > > Lou Berger <[email protected]> wrote: > > > All, > > > > > > This is start of a two week poll on making > > > draft-lengyel-netmod-yang-instance-data-04 a working group > > > document. Please send email to the list indicating "yes/support" or > > > "no/do not support". If indicating no, please state your reservations > > > with the document. If yes, please also feel free to provide comments > > > you'd like to see addressed once the document is a WG document. > > > > > > The poll ends Oct 22. > > > > > > Thanks, > > > > > > Lou (and co-chairs) > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
