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

[Ladislav Lhotka <[e-mail]>]

Robert Wilton <[e-mail]> writes:

> On 09/11/2017 15:37, Ladislav Lhotka wrote:
>> Robert Wilton <[e-mail]> writes:
...

>>>>> 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.
>>> OK, 7950 doesn't define it today.  Is that a problem?
>> "Schema tree" and "schema node" are defined and used a lot in 7950, so
>> it might be good to define "schema" as well - meaning the schema tree
>> with all associated semantics.
> OK, but we can't add definitions to 7950 now.  Would it make sense to 
> add the definition to the NMDA draft and reference that?

Ultimately, these terms belong to the YANG spec, but some termporary
solution might be useful, and the NMDA draft looks like a good
candidate.

...

>>>> But it could also be that such rules are inappropriate in this document and
>>>> rather belong to a protocol spec.
>>> I think that they are OK here if this draft defines the lifetime of the
>>> schema.  If it is just the same as YANG library, then perhaps this could
>>> be left to the YANG library spec to specify?
>>>
>>>>> 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.
>>> An example would presumably be where effectively the same data is being
>>> mounted in a separate place.  E.g. the list of physical interfaces in an
>>> LNE may represent a subset of all physical interfaces in the device,
>>> that would also be present in the host model.
>> Then I would say simply "..., its data will generally have no
>> relationship to the data of the parent, unless the data model explicitly
>> states otherwise."
>>
>> OK, "data model" is another term that isn't defined, but to me it is the
>> collection of YANG modules that define the schema. I think it's not
>> possible to say where the exception has to be stated, it can be
>> either in the parent or in the mounted module, or even elsewhere.
> OK, but I would avoid introducing the term "data model".

Any reason for avoiding it? This term is used quite a lot.

>
>>
>>>>> 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.
>>> In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally
>>> separate from the parent data.  For paragraph 5, I still that it is
>>> useful to state the equivalent that if a schema is mounted twice it
>>> doesn't mean the same data is mounted in both places.
>> This should be absolutely clear to anybody who understands that we are
>> only constructing a schema because, e.g., multiple uses of the same
>> grouping in YANG also don't mean the same instance data. Unfortunately,
>> with schema mount this confusion arises again and again, maybe the term
>> "mount" is really misleading.
> So, I'm not confused by this (but I am quite familiar with the 
> solution), but think that this is an area where a less familiar reader 
> could make the wrong assumption, hence the suggestion to clarify it.
>

Ideally, everybody should understand that schema mount is just another
means for making modular schemas, as augment is. Unfortunately, it seems
that especially the "inline" method attracts instance-related
considerations.

>
>>
>> ...
>>
>>>>> 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.
>>> I was suggesting that it might be useful to add "module" in addition to
>>> namespace.
>> This is possible but redundant, I was thinking about replacing the URIs
>> with module names. It probably doesn't really matter unless the URIs are
>> written by hand.
> I'm wondering whether this list is really required at all.  E.g. if you 
> see my other email about YANG library structure, then if the structure 
> for schema mount and YANG library was converged then would this list 
> still be necessary?  Or could there just be a reference to the parent 
> schema that xpath references are resolved against?

Some kind of prefix definition (be it URI- or module-based, or both), is
still necessary because potentially we can have modules with conflicting
prefixes.

Lada

>
> Thanks,
> Rob
>
>>
>> Lada
>>
>>>>> 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,
>>> Rob
>>>
>>>
>>>> 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
>>>>>> .
>>>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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