[Reducing to just the open threads]
>> 3.1:
>> a) 2nd paragraph, s/defines a label for/defines the label for/
>
> Is this really correct? If we say "the label", it seems that we
> first have to say that such a label exists; otherwise, which label
> does "the label" refer to?
I think so, in that there can only be one, whereas "a label"
sounds less definitive. That said, I imagine this being
something RFC Editor might catch.
>> 3.2, 1st paragraph:
>> a) 1st sentence, s/parent schema/data model supported by the server/?
>
> "parent schema" is a term defined in this document, so I think it is
> appropriate to use it here.
I saw it, but I thought this sentence regarded the data model (a
collection of schema), more so than the parent schema.
>> b) 2nd sentence, s#yangmnt:schema-mounts#/yangmnt:schema-mounts#?
>
> changed to "/schema-mounts". We ususally don't use the prefixes in
> text when we talk about the new module, unless there's a risk of
> confusion.
okay
>> c) 2nd sentence, are mounts as stable as yang library? It seems that
>> if a new LNE were added, that would add a new mount point w/o
>> changing yang library...
>
> Well, adding a new LNE doesn't add a new mount point.
>
> But I think we should remove this sentence; it was appropriate when
> we had the "schema" list, which is now removed.
okay
>> d) perhaps discuss the implications of it being as stable? E.g.,
>> clients only need to check /yangmnt:schema-mounts when yang
>> library's checksum changes?
>
> See above, sentence removed.
okay
> 3.2, 2nd paragraph, can you add a reference to the section in
> rtgwg-lne-model that has the exception, or some text about
> the nature of the exception defined in that document?
did you miss this comment before?
>> 3.2, last paragraph: is "in the operational state"
>
> I don't understand this comment.
Undoubtedly, as I didn't complete it! ;)
Trying again, is "in the operational state" needed in this sentence?
The sentence seems to read better without it. If it is needed, then
can we say it another way or somehow expand on it so it's clear?
>> 3.3: an example would be helpful
>> 5: end of 2nd paragraph, an example would be nice
>
> I will look at this and see if we can add examples.
okay
>> b) in the "mount-point" node's description statement, would it be
>> helpful to add that multiple instances of the mount-point may exist
>> when the extension statement is used in a 'list' or 'grouping' stmt?
>> - this to help with the last paragraph in the description stmts for
>> both the inline and shared-schema nodes?
>
> I don't understand what you suggest should be made more clear. Can
> you propose some text?
Both the inline and shared-schema nodes have this text:
Different instances of the mount point may have
different schemas mounted.";
In particular, I'm looking at "different instances of the mount point"
and wondering under what conditions there might be different instances
of a mount point. My suggestion is to add to the description for
/schema-mounts/mount-point something like:
Different instances of the mount point may occur when the "mount-point"
extension statement is used under a 'list' or a 'grouping'.
>> c) why is "shared-schema" a presence container?
>
> B/c its existence mean that the moint point has a shared schema; it is
> same in all instances of the mount point. Also, the leaf-list in the
> container is optional, so we need the presence to be able to create
> the container w/o any children.
I didn't realize that the leaf-list was optional, even though I saw
that there isn't a 'min-elements' statement. Somehow, I thought that
having a parent reference was what distinguishes it. The text does
state that there can be zero parent references in the 2nd-to-last
paragraph in Section 4 but, when reading the YANG, the description
statements for "inline" and "shared-schema" nodes are identical
except for the bit regarding parent references, which confused me.
>> d) for parent-reference, would it be helpful to note that the reference
>> MAY be to nodes that themselves were brought in via a parent ref, for
>> the nested schema mount case?
>
> Maybe, if it can be expressed in a non-confusing way... I'm not sure
> my first attept fulfils that:
>
> Note that in the case 'ietf-yang-schema-mount' is
> itself mounted, a 'parent-reference' in the mounted
> module may refer to nodes that were brought into the
> accessible tree through a 'parent-reference' in the
> parent schema.";
works for me, and an example illustrating this would be great. I
proposed this before as well.
>> A. shouldn't there be an example parent schema module showing the
>> "mount-point" extension statement defining the "root" label?
>
> The example has:
>
> "mount-point": [
> {
> "module": "ietf-logical-network-element",
> "label": "root",
>
> This means that the "root" label is defined in the module
> "ietf-logical-network-element".
Yes, but it's not obvious, and it is a bit odd in that one might
think that this draft would be written before rtgwg-lne-model.
This section should explain that the mount point defined in that
other draft.
Kent // contributor
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
