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

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Mar 2018 11:39:39 +0000

1: paragraph starting w/ "In some cases", 1st sentence, s/often/sometimes/

2: add ref to RFC 8174

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/
  b) 4th paragraph, add ref to RFC 6020

3.2, 1st paragraph:
 a) 1st sentence, s/parent schema/data model supported by the server/?
 b) 2nd sentence, s#yangmnt:schema-mounts#/yangmnt:schema-mounts#?
 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...
 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?

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"

3.3: an example would be helpful

5: end of 2nd paragraph, an example would be nice

6: 2nd paragraph, is the ref to RFC7950 correct?

9: in the ietf-yang-schema-mount module:
 a) in the top-level description stmt, s/specify/specifies/?
 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?
 c) why is "shared-schema" a presence container?
 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?

A. shouldn't there be an example parent schema module showing the
   "mount-point" extension statement defining the "root" label?

global:
 a) should "data node" be a term?
 b) nowhere is RFC Editor asked to map XXXX to the assigned RFC number
 c) nowhere is RFC Editor asked to map 2018-03-20 to the published date

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Mar 2018 17:12:41 +0000 (GMT)

Thanks for the quick review!  Comments inline.

> 1: paragraph starting w/ "In some cases", 1st sentence, s/often/sometimes/

fixed.

> 2: add ref to RFC 8174

fixed.

>   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.

>  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.

>     if a new LNE were added, that would add a new mount point w/o 

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.

>     library's checksum changes?

See above, sentence removed.

> 3.2, last paragraph: is "in operational state"

I don't understand this comment.

> 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.

>  a) in the top-level description stmt, s/specify/specifies/?

fixed.

>       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.

>     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.";

>    "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".

>  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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Mar 2018 20:38:56 +0000

[Reducing to just the open threads]

> 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.

> 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.

> text when we talk about the new module, unless there's a risk of

okay

> But I think we should remove this sentence; it was appropriate when 
> we had the "schema" list, which is now removed.

okay

> 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"
>

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?

> 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

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'.

> 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.

>             accessible tree through a 'parent-reference' in the

works for me, and an example illustrating this would be great.  I
proposed this before as well.

> "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