Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Ladislav Lhotka <[e-mail]>]

Hi Rob,

thank you for the review, my replies are inline.

Robert Wilton <[e-mail]> writes:

> Hi,
>
> I have read this document and think that is almost ready for publication.
>
> I have one general comment regarding the YANG module library (at the 
> end), and a few nits, but otherwise the draft looks good.
>
> 1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't 
> absolutely clear to me what an internal node is, so I wonder whether 
> this would be more clear as  "internal (i.e. non root) node".

Agreed, but probably with a hyphen: "non-root"?

>
> 2. Sec 1. Introduction, page 4, paragraph starting "2. 
> Implementation-time ...".  This section states that it is a stable as 
> YANG library, and hence cannot change due to a server reboot. However, 
> YANG library doesn't appear to have that restriction, and hence this 
> doesn't seem to align with RFC 7895, introduction paragraph 2.

I don't know exactly under what circumstances YANG library can change
after a reboot, but in such a case schema-mounts data might be subject
to a change as well. I definitely think that the "run-time" case is
something else.

>
> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined 
> anywhere (RFC 7950 doesn't define this).  Should it be defined here?  
> The NMDA datastores draft had a similar issue and we choose to define 
> "datastore schema" instead.

I think the right place for defining the term "schema" (and "data model"
as well) is the specification of YANG because it is desirable that all
documents related to YANG use the same meaning.

>
> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.  
> The text "same management session" might be more clear as "same client 
> management protocol session".

Hmm, I wouldn't say this is more clear - it seems to indicate that we
are managing the client.

But it could also be that such rules are inappropriate in this document and
rather belong to a protocol spec.

>
> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" => 
> "are possible, and as such, needs"

I actually don't understand neither this sentence nor what the point of
such exceptions could possibly be.

>
> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though the 
> schema is the same, the data is different and not necessarily related.

I think this goes without saying, as it is also the case for a single mount
point that is a list node - data in each entry is different.

>
> 7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

Yes.

>
> 8.  Sec 6 Implementation Notes.  Would this section be better named 
> "Implementation Considerations"?

Agreed.

>
> 9. Structure of ietf-yang-schema-mount module:
>    - Should "uri" under namespace be marked as "mandatory" so that it 
> doesn't appear to be optional in the tree diagram.

Yes, this is an omission.

>    - Should the "module" name be included under the namespace.  It seems 
> that lots of other "module bindings" are done via the module name rather 
> than the namespace?

We need it exclusively for XPath, so it seems natural to stay close to XML
namespaces.

>
> 10. Example A.3.  This contains some features that are enabled. Possibly 
> it would be useful in the description to point this out, and state that 
> unless the features are listed they wouldn't be enabled.

Yes, we reuse the groupings from ietf-yang-library, and the idea is to
apply the same semantics. And as you are saying below, it would be more
straightforward to integrate it directly with YANG library. 

>
> My last general comment relates generally to the structure of the 
> Iietf-yang-schema-mount.  As Lada has pointed out previously, this 
> module and YANG library bis could be more closely aligned (e.g. along 
> the lines of reusing module-sets for the "schema" list).  It would have 
> been nice if this module could augment YANG library (so that you can 
> easily get the modules and schema mount information in a single simple 
> request), however that would put an undesired dependency delaying 
> publishing this draft until YANG library bis is completed.

Of course I agree, but I think the priority should be to make things as
simple and easy to understand as possible. They are complex enough
anyway.

Thanks, Lada

>
> Thanks,
> Rob
>
>
> On 20/10/2017 22:37, Kent Watsen wrote:
>> All,
>>
>> This starts a two-week working group last call on
>> draft-ietf-netmod-schema-mount-07.
>>
>> The working group last call ends on November 3.
>> Please send your comments to the netmod mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document
>> and believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Could the authors, explicitly CC-ed on this email,
>> please also confirm one more time that they are
>> unaware of any IPR related to this draft.
>>
>> Thank you,
>> Netmod Chairs
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67