Thanks for the quick review! Comments inline.
Kent Watsen <kwat...@juniper.net> wrote:
>
> 1: paragraph starting w/ "In some cases", 1st sentence, s/often/sometimes/
fixed.
> 2: add ref to RFC 8174
fixed.
> 2.1: s/defines a label for/defines the label for/
> 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?
> b) 4th paragraph, add ref to RFC 6020
fixed.
> 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.
> 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.
> 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.
> 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.
> 3.2, 2nd paragraph, can you add the section in rtgwg-lne-model that
> has the exception, or some text about the nature of the exception
> defined in that document?
>
> 3.2, last paragraph: is "in operational state"
I don't understand this comment.
> 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.
> 6: 2nd paragraph, is the ref to RFC7950 correct?
Nope, should be 7895, fixed.
> 9: in the ietf-yang-schema-mount module:
> a) in the top-level description stmt, s/specify/specifies/?
fixed.
> b) in the "mount-point" container'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?
> 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.
> 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.";
> 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".
> global:
> a) should "data node" be a term?
fixed (imported from 7950)
> b) nowhere is RFC Editor asked to map XXXX to the assigned RFC number
fixed
> c) nowhere is RFC Editor asked to map 2018-03-20 to the published date
fixed
/martin
>
>
> Kent // contributor
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
