Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-rfc7895bis-05.txt

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Mar 2018 15:26:26 +0100

Martin Bjorklund <[email-masked]> writes:

> Hi,
>
> This version addresses the WGLC comments.  Specifially, the module
> list now havs leaf-lists feature/deviation, import the term "implement
> a module" from RFC 7950, rather than redefining the term in this
> document, fixed some typos, fixed the examples to validate, updated
> references.

The draft should address the situation where one or more implemented
modules containing deviations are not listed in the "deviation" leaf-list
of the deviated module.

Currently the contents of the deviation list from sec. 3 is ambiguous in
this situation because

1. such a situation might be considered as an error in server
implementation, but it doesn't follow from the document.

2. deviations from implemented modules are applied no matter what the
"deviation" leaf-lists say.

3, the "deviation" leaf-lists are authoritative, i.e. deviations
appearing in other modules are ignored.

I would personally prefer #3 because it is easiest to handle for both
server implementors and clients.

Lada

>
>
> /martin
>
>
>
> [email-masked] wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Network Configuration WG of the IETF.
>> 
>>         Title           : YANG Library
>>         Authors         : Andy Bierman
>>                           Martin Bjorklund
>>                           Juergen Schoenwaelder
>>                           Kent Watsen
>>                           Robert Wilton
>> 	Filename        : draft-ietf-netconf-rfc7895bis-05.txt
>> 	Pages           : 32
>> 	Date            : 2018-02-27
>> 
>> Abstract:
>>    This document describes a YANG library that provides information
>>    about the YANG modules, datastores, and datastore schemas used by a
>>    network management server.  Simple caching mechanisms are provided to
>>    allow clients to minimize retrieval of this information.  This
>>    version of the YANG library supports the Network Management Datastore
>>    Architecture by listing all datastores supported by a network
>>    management server and the schema that is used by each of these
>>    datastores.
>> 
>>    This document obsoletes RFC 7895.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc7895bis/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-05
>> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-rfc7895bis-05
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc7895bis-05
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 5 Mar 2018 15:22:48 +0000

Hi Lada,

I think that this is just the server providing erroneous data (i.e. 
option 1 below), and as such I think that a client is at liberty to do 
whatever it deems most appropriate.  E.g. I suspect that I would code a 
client to do (2).

Note, that the deviation leaf-list is a leafref back to the module 
list.  Hence, for the YANG instance data to be valid, any entries in the 
deviation list must be included in the modules list.

In theory, a server could populate the module list with deviations but 
not the deviation leaf-list.  However, there is no indication in the 
module description that this is a valid thing to do, or that this 
information is optional.  Stating that this specific information is 
mandatory might then imply that some of the other data in YANG library 
is optional, when it isn't.

In short, having looked at it again, I'm still of the opinion that the 
current text is sufficient.

Do you still think that we need to clarify this further?

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Mar 2018 16:50:51 +0100

> whatever it deems most appropriate.  E.g. I suspect that I would code a 

Whereas the server implementor may go for (3), which results in possible
interoperability problems.

> deviation list must be included in the modules list.

Hmm, even this is actually not true - the type should have

  require-instance true;

right?

But anyway, my point is the opposite direction - a deviation module is in the
"module" list but not in the "deviation" leaf-list.

> module description that this is a valid thing to do, or that this 

But neither is there any indication that it is an invalid thing to do. Having
the deviation modules only in the "module" list would be perfectly sufficient.

> Do you still think that we need to clarify this further?

If "module" and "deviation" are required to match, the document should say so.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Mar 2018 17:01:04 +0100

> Hmm, even this is actually not true - the type should have

Yes, I think this should be there.
 
> If "module" and "deviation" are required to match, the document

Note that section 3 says:

   o  deviation list: The name of each YANG module with deviation
      statements affecting a given YANG module, in a given datastore
      schema, MUST be identified.

I know, this is in the objectives section and not in the YANG
definitions, perhaps we need to make this clear there as well.
Perhaps just change

OLD

     "List of YANG deviation modules used by this server to modify

NEW

     "List of all YANG deviation modules used by this server to modify

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Mar 2018 17:12:09 +0100

>      "List of all YANG deviation modules used by this server to modify

But still it doesn't say how the deviation list is determined from YLbis data. A
server/client implementor may IMO choose any of the three options that I listed.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Mar 2018 17:17:45 +0100

> server/client implementor may IMO choose any of the three options that I listed.

A server has to list _all_ deviation modules and I thought this takes
care of things. The reason for having this list is that a client
interested in say ietf-interfaces can directly find the modules that
contain deviations affecting ietf-interfaces. Hence a client has to
trust this list to be complete, i.e., the server has to report _all_
deviation modules. If you still feel something is missing, perhaps it
helps if you propose concrete text.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Mar 2018 16:45:57 +0100

> helps if you propose concrete text.

The server can include deviation modules in the YLbis "module" list. Now, the
question is whether this is enough, no matter what the "deviation"
leaf-lists say. It makes no sense to propose any text before we agree on
the answer to this question.

Note that one module can possibly include deviations for multiple target
modules. An implementor may then decide to apply deviations only to some
modules, and this can be effectively done through the "deviation"
leaf-lists.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Mar 2018 16:50:54 +0100

> the answer to this question.

The server is expected to list _all_ deviation modules that apply to a
given module. You do not agree with this?

> modules, and this can be effectively done through the "deviation"

No, this is not how YANG works. There is no notion of a conditional
deviation depending on some external information.

The deviation leaf-list is a fast lookup mechanism so that a client
does not have to parse a potentially large set of modules for any
deviations. It does not change YANG semantics.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Mar 2018 17:54:59 +0000 (GMT)

> Yes, I think this should be there.

But require-instance defaults to "true", so it is not needed.

>      "List of all YANG deviation modules used by this server to modify

Ok, this makese sense.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Mar 2018 18:07:11 +0000

> But require-instance defaults to "true", so it is not needed.

Right, my fault, I thought the default is "false".

Lada