Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

[Juergen Schoenwaelder]

This is discussed in section 1 of draft-ietf-netconf-rfc7895bis-06.txt.

/js

On Wed, May 30, 2018 at 01:56:14AM +, Qin Wu wrote:
> Juergen:
> One stupid question I have is, What about the old client and server still 
> support YANG 1.0 since RFC7895bis is designed to replaces RFC7895?
> Do we have transition stage before RFC7895bis takes effect?
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2018年5月29日 20:06
> 收件人: Rohit R Ranade
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> 
> Yes, this is why we have draft-ietf-netconf-rfc7895bis-06.txt.
> 
> /js
> 
> On Tue, May 29, 2018 at 11:27:42AM +, Rohit R Ranade wrote:
> > Hi Juergen,
> > 
> > Consider a device supports a dynamic data-store called "ephemeral". 
> > Consider Yang-library 1.1 is NOT implemented in device.
> > Consider device have 3 Modules ==> Module1 ,  Module2-state and 
> > Module3
> > 
> > Module1 : Supported in  and  Module2-state : 
> > Supported only in 
> > Module3 : Supported only in 
> > 
> > So here assumption is that Client knows he cannot do  on 
> > Module2-state as it has only read-only nodes.
> > But Client does not know the modules in ephemeral and depends on 
> > yang-library 1.1 to know whether an edit-data can be done on Module3 ?
> > 
> > Which modules are supported in which data-stores is not known to Client 
> > without Yang-library 1.1 ?
> > 
> > With Regards,
> > Rohit R Ranade
> > 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > [mailto:j.schoenwael...@jacobs-university.de]
> > Sent: 29 May 2018 16:36
> > To: Rohit R Ranade 
> > Cc: Robert Wilton ; netmod@ietf.org
> > Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> > 
> > On Tue, May 29, 2018 at 10:44:04AM +, Rohit R Ranade wrote:
> > > Hi Robert,
> > > 
> > > The Introduction section has :
> > > "
> > > Furthermore, the operational state datastore may support non-configurable 
> > > YANG modules in addition to
> > >the YANG modules supported by conventional configuration datastores.
> > > "
> > > I infer that in the new Yang-library structure,  the schema for 
> > > "conventional" data-stores should not include the non-configurable YANG 
> > > module. Is my inference correct ?
> > >
> > 
> > A module that has only config false nodes will not add anything to a 
> > conventional configuration datastore but it is not an error list such a 
> > module. For a simple devices, it may be desirable to have just one schema 
> > that applies to all datastores. There is no requirement to break things 
> > apart just because there is a module that contributes only an empty set to 
> > conventional configuration datastores.
> > 
> > Note that the defined term is 'conventional configuration datastore'
> > and not 'conventional datastore'. Oops, I see that in one place 
> > draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part of 
> > the term. That should be fixed.
> > 
> > OLD
> > 
> >The recommended approach to populate "/modules-state" is to report
> >the schema for YANG modules that are configurable via conventional
> >datastores and for which config false data nodes are returned via a
> >NETCONF  operation, or equivalent.
> > 
> > NEW
> > 
> >The recommended approach to populate "/modules-state" is to report
> >the schema for YANG modules that are configurable via conventional
> >configuration datastores and for which config false data nodes are
> >returned via a NETCONF  operation, or equivalent.
> > 
> > Co-authors, if you agree, how do we track this?
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

[Juergen Schoenwaelder]

On Wed, May 30, 2018 at 05:21:29AM +, Rohit R Ranade wrote:
> 
> Also what does it mean that state-modules have been "implemented" in the 
>  data-store ?
>

The server implemented an empty set of objects. No client should have
an issue with that and a server may choose to report this (for example
if the server wants to have a single schema for all datastores).

I do not see why making this illegal would simplify anything. It seems
making this illegal just adds complexity for no value.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Status update on

[Qin Wu]

Hi, WG:
We have made an update Documentation Conventions for Expressing YANG in XML I-D 
based on last meeting discussion.
The changes include:
1. Add JSON support.
2. Add objectives section 
3. Consolidate Mandatory Boilerplate for both leaf node and metadata annotation.
4. Move complex case to Appendix.
5. Better Align abstract and introduction section with objectives sections.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-01
We believe the v-(01) address all the comments in last meeting and can serve a 
good basis to move to the next step.
Thanks. Further Comments and suggestions are welcome.

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2018年5月30日 9:17
收件人: Benoit Claise; Qin Wu; Adrian Farrel; Benoît Claise
主题: New Version Notification for draft-wu-netmod-yang-xml-doc-conventions-01.txt


A new version of I-D, draft-wu-netmod-yang-xml-doc-conventions-01.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-wu-netmod-yang-xml-doc-conventions
Revision:   01
Title:  Documentation Conventions for Expressing YANG in XML
Document date:  2018-05-29
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-wu-netmod-yang-xml-doc-conventions-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-wu-netmod-yang-xml-doc-conventions/
Htmlized:   
https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-conventions-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wu-netmod-yang-xml-doc-conventions
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-yang-xml-doc-conventions-01

Abstract:
   Many documents that define YANG modules also include artwork examples
   presented in XML/JSON.

   IETF documentation has specific limits on line length and some
   artwork examples such as XML examples have to include line wraps that
   would not normally be allowed according to the XML representation
   rules of RFC7950 and RFC7952.The same applies to JSON.

   This document lays out documentation conventions that allow YANG
   examples to be presented in IETF documentation when XML/JSON encoded
   YANG data instance would otherwise exceed the maximum line length and
   provide consistent XML/JSON encoded YANG data node instance example
   within an Internet-Draft or RFC.  There are no implications in this
   document for YANG parsers: this document does not change the rules
   for presenting YANG models or for encoding YANG in data files or in
   the wire.


  


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.

The IETF Secretariat

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Juergen Schoenwaelder]

On Tue, May 29, 2018 at 03:58:33PM +, Kent Watsen wrote:
> [resurrecting this thread]
> 
> Currently the zerotouch draft has a normative reference to this draft.
> I will this week post an update to the zerotouch draft to resolve the
> netconf list thread "a couple zerotouch-21 issues".   It would be easy
> for me to also switch back to using rc:yang-data, but I won't do so if
> this draft remains an active work-in-progress.
> 
> Please see below for more.
> 
> 
> On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> >> 
> >> The primary use case is not "generic RPC messages", but standalone
> >> instance documents, error-info structures, etc.
> >
> > The proper solution for rpcs and actions is to define error
> > information as part of the rpc/action. YANG 1.1 does not support
> > this but this is where it should be fixed.
> 
> Agreed, but note that the subscribed-notifications draft (both the
> published -12 and unpublished -13) are relying on being able to do
> just this, and YANG-next is years away...

There is a description statement.

> > Standalone instance documents (not tied to datastores) may have their
> > use cases as well but it feels odd to create support for standalone
> > instance documents as extensions and then to create even more
> > extensions to support augmentation of these instance documents and
> > whoever knows what comes next.
> 
> What feels "odd" about this?  Is it not using the extension statement
> as it was intended?

For me, extensions that define new data definition statements are
borderline. RFC 7950 has this nice statement:

   o  extension: An extension attaches non-YANG semantics to statements.
  The "extension" statement defines new statements to express these
  semantics.

This does not help since we lack a definition for 'non-YANG semantics'
and yes I know that yang-data is today defined as an extension. But
for me, this is a hack and instead of creating a slightly more
generalized version of this hack, I prefer to stick to yang-data in
favor of a proper solution as part of YANG.
 
> > For short-term needs, there is yang-data defined in RFC 8040.
> 
> To be clear, the "short-term needs" are:
> 
>   a) zerotouch: to define a standalone instance document
>   b) notification-messages: to define a new notification message
>   c) subscribed-notifications: to define error-info structures
> 
> As I recall, this draft (not RFC 8040) is needed:
> 
>   - for (a), because rc:yang-data doesn't support a top-level
> "choice" statement spanning "container" statements.

So create a container.
 
>   - for (b), in order to augment a base yang-data "message" 
> structure with additional nodes.

So you are creating another augmentation mechanism. I am concerned
about ending up with a zoo of different mechanisms if we go down this
path, we may end up with every project or vendor creating their own
variants.

With NMDA in place, YANG 1.1 is decribing schemas for datastores plus
operations and notifications. It is not a protocol message description
language or a standalone file format description language. If this is
needed, I prefer to create YANG X.Y - and if we manage the complexity
we have something that is ideally integrated and consistent.

>   - AFAIAA, RFC 8040 is sufficient for (c)
> 
> Has anything changed?   I don't think that we can un-adopt this
> draft with said dependencies, right?

I am just voicing my opinion. It may very well be that the WG prefers
to go the route of not touching YANG 1.1 and instead patching around
its limitations with extensions.

My concern is simply driven that some want to patch in via extensions
support for describing protocol messages and standalone documents,
others want to patch via extensions and updates a different versioning
system, and who knows what comes next. In the long run, I am afraid
this will become a mess. And yes, it is always difficult to predict
the future - we need crystal balls. Perhaps as an extension. ;-)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Kent Watsen]

[resurrecting this thread]

Currently the zerotouch draft has a normative reference to this draft.
I will this week post an update to the zerotouch draft to resolve the
netconf list thread "a couple zerotouch-21 issues".   It would be easy
for me to also switch back to using rc:yang-data, but I won't do so if
this draft remains an active work-in-progress.

Please see below for more.


On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
>On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
>> 
>> The primary use case is not "generic RPC messages", but standalone
>> instance documents, error-info structures, etc.
>
> The proper solution for rpcs and actions is to define error
> information as part of the rpc/action. YANG 1.1 does not support
> this but this is where it should be fixed.

Agreed, but note that the subscribed-notifications draft (both the
published -12 and unpublished -13) are relying on being able to do
just this, and YANG-next is years away...


> Standalone instance documents (not tied to datastores) may have their
> use cases as well but it feels odd to create support for standalone
> instance documents as extensions and then to create even more
> extensions to support augmentation of these instance documents and
> whoever knows what comes next.

What feels "odd" about this?  Is it not using the extension statement
as it was intended?


> For short-term needs, there is yang-data defined in RFC 8040.

To be clear, the "short-term needs" are:

  a) zerotouch: to define a standalone instance document
  b) notification-messages: to define a new notification message
  c) subscribed-notifications: to define error-info structures


As I recall, this draft (not RFC 8040) is needed:

  - for (a), because rc:yang-data doesn't support a top-level
"choice" statement spanning "container" statements.

  - for (b), in order to augment a base yang-data "message" 
structure with additional nodes.

  - AFAIAA, RFC 8040 is sufficient for (c)


Has anything changed?   I don't think that we can un-adopt this
draft with said dependencies, right?


Kent



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

[Kent Watsen]

> Co-authors, if you agree, how do we track this?

As co-author, I agree and view it as an editorial update.  

As co-chair, I recommend the authors commit the fix to 
GitHub now and wait for AD and/or IESG reviews to trigger
an update that it will get swept into.  I don't think that
it's worth fixing any sooner than that, and yet also fear
risking it will be forgotten.

Kent



On Tue, May 29, 2018 at 10:44:04AM +, Rohit R Ranade wrote:
> Hi Robert,
> 
> The Introduction section has :
> "
> Furthermore, the operational state datastore may support non-configurable 
> YANG modules in addition to
>the YANG modules supported by conventional configuration datastores.
> "
> I infer that in the new Yang-library structure,  the schema for 
> "conventional" data-stores should not include the non-configurable YANG 
> module. Is my inference correct ?
>

A module that has only config false nodes will not add anything to a
conventional configuration datastore but it is not an error list such
a module. For a simple devices, it may be desirable to have just one
schema that applies to all datastores. There is no requirement to
break things apart just because there is a module that contributes
only an empty set to conventional configuration datastores.

Note that the defined term is 'conventional configuration datastore'
and not 'conventional datastore'. Oops, I see that in one place
draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part
of the term. That should be fixed.

OLD

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   datastores and for which config false data nodes are returned via a
   NETCONF  operation, or equivalent.

NEW

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   configuration datastores and for which config false data nodes are
   returned via a NETCONF  operation, or equivalent.

Co-authors, if you agree, how do we track this?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=fL-imGAsOCm0vM-RDRMkiRFU-5x4dLkKa5-hBOU9Iys=i4-lwMctjujC_UiZmGO4s83-jyKmw7jbGsS0cLfFZT4=


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

[Juergen Schoenwaelder]

Yes, this is why we have draft-ietf-netconf-rfc7895bis-06.txt.

/js

On Tue, May 29, 2018 at 11:27:42AM +, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Consider a device supports a dynamic data-store called "ephemeral". Consider 
> Yang-library 1.1 is NOT implemented in device.
> Consider device have 3 Modules ==> Module1 ,  Module2-state and Module3
> 
> Module1 : Supported in  and 
> Module2-state : Supported only in 
> Module3 : Supported only in 
> 
> So here assumption is that Client knows he cannot do  on 
> Module2-state as it has only read-only nodes.
> But Client does not know the modules in ephemeral and depends on yang-library 
> 1.1 to know whether an edit-data can be done on Module3 ?
> 
> Which modules are supported in which data-stores is not known to Client 
> without Yang-library 1.1 ?
> 
> With Regards,
> Rohit R Ranade
> 
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> Sent: 29 May 2018 16:36
> To: Rohit R Ranade 
> Cc: Robert Wilton ; netmod@ietf.org
> Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
> 
> On Tue, May 29, 2018 at 10:44:04AM +, Rohit R Ranade wrote:
> > Hi Robert,
> > 
> > The Introduction section has :
> > "
> > Furthermore, the operational state datastore may support non-configurable 
> > YANG modules in addition to
> >the YANG modules supported by conventional configuration datastores.
> > "
> > I infer that in the new Yang-library structure,  the schema for 
> > "conventional" data-stores should not include the non-configurable YANG 
> > module. Is my inference correct ?
> >
> 
> A module that has only config false nodes will not add anything to a 
> conventional configuration datastore but it is not an error list such a 
> module. For a simple devices, it may be desirable to have just one schema 
> that applies to all datastores. There is no requirement to break things apart 
> just because there is a module that contributes only an empty set to 
> conventional configuration datastores.
> 
> Note that the defined term is 'conventional configuration datastore'
> and not 'conventional datastore'. Oops, I see that in one place 
> draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part of the 
> term. That should be fixed.
> 
> OLD
> 
>The recommended approach to populate "/modules-state" is to report
>the schema for YANG modules that are configurable via conventional
>datastores and for which config false data nodes are returned via a
>NETCONF  operation, or equivalent.
> 
> NEW
> 
>The recommended approach to populate "/modules-state" is to report
>the schema for YANG modules that are configurable via conventional
>configuration datastores and for which config false data nodes are
>returned via a NETCONF  operation, or equivalent.
> 
> Co-authors, if you agree, how do we track this?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

[Robert Wilton]

Hi Rohit,


On 29/05/2018 10:35, Rohit R Ranade wrote:


Hi All,

Consider the below YANG tree, which contains both “rw” and “ro” nodes.

module: ietf-interfaces

    +--rw interfaces

    |  +--rw interface* [name]

    | +--rw name    string

    | +--rw description?    string

    | +--rw type    identityref

    | +--rw enabled?    boolean

    | +--rw link-up-down-trap-enable?   enumeration {if-mib}?

    | +--ro admin-status    enumeration {if-mib}?

    | +--ro oper-status enumeration

    | +--ro last-change?    yang:date-and-time

    | +--ro if-index    int32 {if-mib}?

    | +--ro phys-address?   yang:phys-address

    | +--ro higher-layer-if*    interface-ref

From what I understand, in the new yang-library structure the schema 
for  data-store will have the complete YANG tree. The 
schema for  will need to add deviations with “not-supported” 
for all the “ro” nodes for this module ?


No need for the deviations for .   only contains the 
"config true" parts of the schema.


So, for a normal, NMDA compliant server, the same schema can be used for 
all datastores.


Thanks,
Rob



With Regards,

Rohit R Ranade



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod