Hi, Ok, in any case, my original point was regarding the ambiguity in the wording "specifies the mounted schema".
The additional text can be dropped if it is deemed to not be adding value. Kind regards, Hayden -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Wednesday, 8 August 2018 8:02 PM To: Hayden Brown Cc: [email protected] Subject: EXTERNAL: Re: [netmod] Fwd: Re: YANG schema mount - any early implementations? Hi, I'm not sure if these changes make the doc better. "how the schema is mounted" is not just "inline" / "shared-schema", but there is also the "config" leaf. And having to repeat that in many places makes the text a bit clumsy imo. Maybe others can chime in as well? /martin Hayden Brown <[email protected]> wrote: > Hi Martin, > > Thank you for your comments. Ok, agreed - it would be better to not introduce > a new mounted-schema 'type' term. Perhaps the wording "how the schema is > mounted" is a better alternative? > I've provided possible wording suggestions again below in brackets. > > > Section 3.3 – Page 7 > The "/schema-mounts" container has the "mount-point" list as one of its > children. Every entry of this list refers through its key to a mount point > and specifies [how the schema is mounted, as either "inline" or > "shared-schema"]. > > > Section 3.3 - Page 8 > An entry of the "mount-point" list can specify [how the schema is mounted] in > two different ways, "inline" or "shared-schema". > > > Section 9 - Page 13 > A mount point defines a place in the node hierarchy where other data models > may be attached. A server that implements a module with a mount point > populates the /schema-mounts/mount-point list with detailed information on > [whether the data models mounted at each instance of a mount point MAY be > different ("inline" case) or if they MUST all have the same YANG library > checksum ("shared-schema" case). ] > > [For a "shared-schema" mount-point list entry, the entry MAY include one or > more "parent-reference" list entries that are used to specify the context > nodeset for any XPath 1.0 expressions defined within the mounted schema.] > > > Section 9 - Page 14 > list mount-point { > key "module label"; > description > "Each entry of this list specifies [how the] schema for a particular > mount point [is mounted ("inline" or "shared-schema"). ] > > > Regards, > Hayden > > > > > > -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: Monday, 6 August 2018 11:06 PM > To: Hayden Brown > Cc: [email protected] > Subject: EXTERNAL: Re: [netmod] Fwd: Re: YANG schema mount - any early > implementations? > > Hi, > > Hayden Brown <[email protected]> wrote: > > Hi Lou, > > > > > > Thank you for your response. In the new copy of the sections below I've > > attempted to convey how I think the paragraphs could read. > > > > > > In my mind, the main "point of ambiguity" is that it seemed the existing > > wording implies: > > > > * the mount-point list specifies which modules are mounted below the > > root of the mount point. > > > > however, I think we have all agreed that: > > > > * the mount-point list specifies the parent module that contains the > > mount-point,. > > > > I see this as just a subtle interpretation difference in the wording > > "specifies the mounted schema". > > > > > > > > Hopefully the wording (edited in the brackets) below better conveys my > > thoughts. Please feel free to correct me, or improve the wording below as > > you see fit. > > > > Section 3.3 – Page 7 > > > The "/schema-mounts" container has the "mount-point" list as one of its > > > children. Every entry of this list refers through its key to a mount > > > point and specifies the [type of] mounted schema [as "inline" or > > > "shared-schema"]. > > > > Section 3.3 - Page 8 > > > An entry of the "mount-point" list can specify the [type of] mounted > > > schema in two different ways, "inline" or "shared-schema". > > The document does not define the "type" of a mounted schema, so I > don't think we should use that term in just a few places. > > > Section 9 - Page 13 > > > A mount point defines a place in the node hierarchy where other data > > > models may be attached. A server that implements a module with a mount > > > point populates the /schema-mounts/mount-point list with detailed > > > information on whether the [data models mounted at each instance of a > > > mount point MAY be different ("inline" case) or MUST all have the same > > > YANG library checksum ("shared-schema" case). > > > > For a "shared-schema" mount-point list entry, the entry MAY include one or > > more "parent-reference" list entries that are used to specify the context > > nodeset for any XPath 1.0 expressions defined within the mounted schema.] > > > > > > Section 9 - Page 14 > > list mount-point { > > key "module label"; > > description > > "Each entry of this list specifies [the type of] schema for a > > particular mount point [ ("inline" or "shared-schema") ]. > > > > > > Thanks and best regards, > > > > Hayden > > > > > /martin > > > > > > > > > > > > > ________________________________ > > From: Lou Berger <[email protected]> > > Sent: Friday, 3 August 2018 7:28 a.m. > > To: Hayden Brown; [email protected] > > Subject: EXTERNAL: Re: [netmod] Fwd: Re: YANG schema mount - any early > > implementations? > > > > > > Hi, > > > > hopefully others will chime in too, but here's my view (as a user of > > schema mount, see https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model)... > > > > On 7/30/2018 7:27 PM, Hayden Brown wrote: > > > > Hi everyone, > > > > I just wanted to ask if it would be possible to clarify the intentions > > around some of the wording of the draft schema mount standard (Rev-10). In > > particular, regarding entries of the /schema-mounts/mount-points list. > > > > My interpretation is that the intended use of the > > /schema-mounts/mount-points list entries are to specify the parent modules > > that contain a mount point. > > > > yes > > > > Following on from this, the client should use the YANG library instance to > > determine which schema options can be mounted at the root of a mount point. > > This seems consistent with the examples of Appendix A of the draft standard. > > > > if you drop the word "options", then yes. Other examples can be found in > > draft-ietf-rtgwg-ni-model > > > > > > In this email I wanted to highlight the following sections of the draft RFC > > below. In my view they seem to me to be somewhat ambiguous, in implying > > that the mount-point list entries specify the *child* module (sub-schema): > > > > > > >From > > >https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/?include_text=1 > > Section 3.3 – Page 7 > > > The "/schema-mounts" container has the "mount-point" list as one of its > > > children. Every entry of this list refers through its key to a mount > > > point and specifies the mounted schema. > > > > Section 3.3 - Page 8 > > > An entry of the "mount-point" list can specify the mounted schema in two > > > different ways, "inline" or "shared-schema". > > > > > > Section 9 - Page 13 > > > A mount point defines a place in the node hierarchy where other data > > > models may be attached. A server that implements a module with a mount > > > point populates the /schema-mounts/mount-point list with detailed > > > information on which data models are mounted at each mount point. > > > > Section 9 - Page 14 > > list mount-point { > > key "module label"; > > description > > "Each entry of this list specifies a schema for a particular mount > > point. > > > > > > I have reread the a few times and am having a hard time understand what > > should be changed. Can you suggest specific changes that would address > > your concern/comment? This might help to understand the issue you are > > seeing. > > > > > > The wording makes me wonder if these passages might actually just be > > "left-over" context from earlier revisions of the draft standard (Revision > > 8 and prior) -- effectively referring back to the schema-mount 'use-schema' > > list. > > > > Again, I'm seeing the issue. > > > > > > I do of course acknowledge that it is entirely possible that I've > > misinterpreted the wording of the passages above, however if that is the > > case, I suspect I may not be the only one in future. > > And I'm sure I'm suffering from having spent way too much time on this > > topic so may be seeing things in the text that aren't actually there! > > > > Cheers, > > Lou > > (no hats) > > > > > > Many thanks for your time on this matter. > > > > Best regards, > > Hayden > > > > > > > > > > > > > > > > On 20/07/2018 8:09 PM, Juergen Schoenwaelder wrote: > > > > On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote: > > > > > > > > I understand that the schema mount proposal is still effectively in a > > > > state of flux, but are there any publicly visible implementations or > > > > deployments of a NETCONF or RESTCONF server that those interested could > > > > experiment with (e.g. to aid in client development)? > > > > > > > > State of flux? It is past WG last call and IETF last call. > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/history/ > > > > > > > > /js > > > > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected]<mailto:[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
