Juergen Schoenwaelder <[email protected]> wrote: > On Tue, Apr 10, 2018 at 10:58:00PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder <[email protected]> wrote: > > > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote: > > > > > > > > > > Yes, the checksum (which I think is actually a version identifier). > > > > > Anyway, the question is whether a client can draw any conclusions from > > > > > seeing YANG library instances with the same checksum and whether a > > > > > client must simpy treat this as a clash. If multiple mounted schemas > > > > > have the same YANG library, then reading one of them would be > > > > > sufficient. The question is whether the checksum is a tool for > > > > > deciding whether a YANG library is similar to an already known one or > > > > > whether a client must not make this assumption, i.e., a checksum is > > > > > always scoped to the YANG library instance and you have to read them > > > > > all. > > > > > > > > Options: > > > > > > > > 1. Be silent about the YL checksum in this document. > > > > > > > > 2. State that the server MUST ensure that if two mounted YL > > > > instances have the same checksum, then the YL contents MUST be > > > > the same. > > > > > > > > 3. State that just b/c the YL checksum is the same in two mounted > > > > instances, it does not mean that the YL contents is the same. > > > > > > > > 4. State that for use-schema, the YL contents and YL checksum MUST be > > > > the samem but for inline, equal YL checksum is no guarantee for > > > > equal YL contents. > > > > > > > > From a client perspective, 2 is preferrable. It is probably not > > > > difficult to implement on a server either; except in the peer mount > > > > case where the data is just read from some device. > > > > > > The more I think about it, it seems option 4. is the right thing to > > > do. > > > > Ok. How about adding two sentences at the end of the last paragraph > > in section 3.3, giving: > > > > The mounted schema is determined at run time: every instance of the > > mount point that exists in the operational state MUST contain a copy > > of YANG library data that defines the mounted schema exactly as for > > a top-level schema. A client is expected to retrieve this data from > > the instance tree, possibly after creating the mount point. In the > > "inline" case, instances of the same mount point MAY use different > > mounted schemas, whereas in the "shared-schema" case, all instances > > MUST use the same mounted schema. In the "inline" case, if two > > instances have the same YANG library checksum it is not guaranteed > > that the YANG library contents are equal for these instances. > > This text says "A client is expected to retrieve this data from the > instance tree, possibly after creating the mount point.", which seems > a bit odd. How does a client create a mount point? First, a mount > point is created by defining it in a YANG module, so this is > specification time not runtime. Perhaps you mean 'instantiated' rather > than 'created' but even then it is somewhat unclear how a client does > that in general. Perhaps simple drop ', possibly after creating the > mount point'.
Ok, I will do that. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
