Re: [netmod] kw review of draft-ietf-netmod-schema-mount-09

[Martin Bjorklund <[e-mail]>]

Thanks for the quick review!  Comments inline.


Kent Watsen <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>