Re: [netmod] New Version Notification for draft-wang-netmod-module-revision-management-00.txt

[wangzitao]

Dear WG,
We prepared a document to introduce a method for module revisions management.
It could be useful for indicating the details changes of different module 
revisions,
and helping the user to manage all the revisions of that module and keep track 
of module. 

Please review it. Comments, suggestions are welcome!

Best Regards!
-Michael

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2018年2月13日 14:09
收件人: wangzitao ; Qin Wu ; wangzitao 

主题: New Version Notification for 
draft-wang-netmod-module-revision-management-00.txt


A new version of I-D, draft-wang-netmod-module-revision-management-00.txt
has been successfully submitted by Michael Wang and posted to the IETF 
repository.

Name:   draft-wang-netmod-module-revision-management
Revision:   00
Title:  A YANG Data Model for module revision management
Document date:  2018-02-12
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-wang-netmod-module-revision-management-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-netmod-module-revision-management/
Htmlized:   
https://tools.ietf.org/html/draft-wang-netmod-module-revision-management-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-netmod-module-revision-management-00


Abstract:
   This document defines a YANG Data Model for module revision
   management.  It is intended this model be used by vendors who support
   multiple revisions of the same YANG module in their systems but
   implement one revision of a module.  In addition, this document
   introduces a new generic mechanism based on RPC, denoted as module-
   revision-change, that allow to report discrepancy information of a
   YANG module with two or multiple revisions that is defined in design
   time., e.g.,identifies a place in the node hierarchy where data node
   gets changed or new data gets inserted and indicate whether the
   change to the data node is backward compatible.


  


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

[netmod] Publication has been requested for draft-ietf-netmod-syslog-model-20

[Kent Watsen]

Kent Watsen has requested publication of draft-ietf-netmod-syslog-model-20 as 
Proposed Standard on behalf of the NETMOD working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

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

Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Andy Bierman]

On Mon, Feb 12, 2018 at 9:29 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote:
> > On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> > > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
> > >
> > > > > >  Sec. 1 - YANG library stability
> > > > > >
> > > > > >  The text basically says that the YANG library information
> can
> > > > > >  change at any time. This has been recently discussed but I
> > > > > >  haven't seen any conclusion yet. I understand it is
> difficult to
> > > > > >  enumerate all the situations when this information can
> change,
> > > > > >  but it should also be emphasized that YL info is not just
> another
> > > > > >  subtree of state data and that it should not change
> haphazardly.
> > > > >
> > > > > I agree, but I think that YANG library's job is to report what the
> > > > > server implements.  If the server dynamically changes its set of
> > > > > loaded modules, then YL should adapt.
> > > > >
> > > > > I welcome more discussion on this topic, but I don't think it has
> to
> > > > > be documented in this draft.
> > > >
> > > > What about this?
> > > >
> > > > OLD
> > > >The YANG library information can be different on every server and
> it
> > > >can change at runtime or across a server reboot.  If a server
> > > >implements multiple network management protocols to access the
> > > >server's datastores, then each such protocol may have its own
> > > >conceptual instantiation of the YANG library.
> > > >
> > > > NEW
> > > >The YANG library information represents a management API for a
> given
> > > > server,
> > > >and should therefore be as stable as possible. The circumstances
> under
> > > > which
> > > >this information can change are outside the scope of this
> document but it
> > > > is
> > > >advisable to consider potential impact on clients.
> > >
> > > I like the old text because it tells the client clearly that this data
> > > can change. And the statement has been in RFC 7895 in the exact same
> >
> > My problem with the current text is that it seems to make no difference
> between
> > YANG library and any other state data.
>
> The sentence starts with 'The YANG library information' and what
> follows is all scoped to 'YANG library information'.
>
> > > wording. If you want to add a statement that servers should not change
> > > the YANG library without reason I could live with that but any attempt
> > > to write text that makes the server somewhat guilty when a client is
> >
> > Not guilty but careful. There is no requirement that clients check YANG
> library
> > between every two operations, and notifications are optional.
>
>
> So let me try to make an alternate proposal. (I only added the second
> sentence.)
>
> NEW:
>
>The YANG library information can be different on every server and
>it can change at runtime or across a server reboot. Servers may
>schedule YANG library changes in way that minimizes the impact on
>active clients. If a server implements multiple network management
>protocols to access the server's datastores, then each such
>protocol may have its own conceptual instantiation of the YANG
>library.
>
> > > not prepared to handle a YANG library change is IMHO a fundamental
> > > change from what RFC 7895 said.
> > >
> > > > > >  It is like with database schemas, REST APIs and the like. Of
> > > > > >  course, these can change as well, but everybody has to
> understand
> > > > > >  that doing so means transition problems, broken clients etc.
> > > > > >
> > > > > >  For this reason, it might be useful to set YL and schema
> mount
> > > > > >  data aside and call them metadata or schema information -
> even if
> > > > > >  we continue modelling them with YANG.
> > > > >
> > > > > Do you have some concrete proposal for where to introduce this
> term?
> > > >
> > > > In RESTCONF it could be a separate well-known resource outside all
> > > > datastores.
> > >
> > > Putting the data into a different place does not change the impact of
> > > the data changing. So I do not understand which problem introducing
> > > yet another datastore solves.
> >
> > Nothing except emphasizing the difference between data and metadata,
> which is
> > IMO an important one.
>
> So its a different topic - one that we closed before I thought.
>
> > > > > >  Sec. 4 - checksum
> > > > > >
> > > > > >  I think it would be very useful (even if not immediately) to
> > > > > >  standardize the procedure for computing the checksum. What I
> > > > > >  envision are systems that construct and process YANG schemas
> > > > > >  (such as the YANG Catalog). They could benefit from having a
> > > > > >  universal hash string as a characteristic of any particular
> > > > > >  schema. Just consider how useful the universal hashes 

Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Andy Bierman]

On Mon, Feb 12, 2018 at 6:37 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
>
> > > >  Sec. 1 - YANG library stability
> > > >
> > > >  The text basically says that the YANG library information can
> > > >  change at any time. This has been recently discussed but I
> > > >  haven't seen any conclusion yet. I understand it is difficult to
> > > >  enumerate all the situations when this information can change,
> > > >  but it should also be emphasized that YL info is not just
> another
> > > >  subtree of state data and that it should not change haphazardly.
> > >
> > > I agree, but I think that YANG library's job is to report what the
> > > server implements.  If the server dynamically changes its set of
> > > loaded modules, then YL should adapt.
> > >
> > > I welcome more discussion on this topic, but I don't think it has to
> > > be documented in this draft.
> >
> > What about this?
> >
> > OLD
> >The YANG library information can be different on every server and it
> >can change at runtime or across a server reboot.  If a server
> >implements multiple network management protocols to access the
> >server's datastores, then each such protocol may have its own
> >conceptual instantiation of the YANG library.
> >
> > NEW
> >The YANG library information represents a management API for a given
> server,
> >and should therefore be as stable as possible. The circumstances
> under which
> >this information can change are outside the scope of this document
> but it is
> >advisable to consider potential impact on clients.
>
> I like the old text because it tells the client clearly that this data
> can change. And the statement has been in RFC 7895 in the exact same
> wording. If you want to add a statement that servers should not change
> the YANG library without reason I could live with that but any attempt
> to write text that makes the server somewhat guilty when a client is
> not prepared to handle a YANG library change is IMHO a fundamental
> change from what RFC 7895 said.
>
>
I strongly oppose changing this text.
Any server that can load or unload modules at run-time can change
the YANG library at run-time.


Andy


> > > >  It is like with database schemas, REST APIs and the like. Of
> > > >  course, these can change as well, but everybody has to
> understand
> > > >  that doing so means transition problems, broken clients etc.
> > > >
> > > >  For this reason, it might be useful to set YL and schema mount
> > > >  data aside and call them metadata or schema information - even
> if
> > > >  we continue modelling them with YANG.
> > >
> > > Do you have some concrete proposal for where to introduce this term?
> >
> > In RESTCONF it could be a separate well-known resource outside all
> datastores.
>
> Putting the data into a different place does not change the impact of
> the data changing. So I do not understand which problem introducing
> yet another datastore solves.
>
> > > >  Sec. 4 - checksum
> > > >
> > > >  I think it would be very useful (even if not immediately) to
> > > >  standardize the procedure for computing the checksum. What I
> > > >  envision are systems that construct and process YANG schemas
> > > >  (such as the YANG Catalog). They could benefit from having a
> > > >  universal hash string as a characteristic of any particular
> > > >  schema. Just consider how useful the universal hashes are e.g.
> in
> > > >  git.
> > >
> > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > not needed immediately for this document.
> >
> > Checksums are mandatory, so every implementation has to invent some
> scheme.
> >
> > Actually, it might be useful to have checksums also on module-sets,
> schemas and
> > datastores so that the client can easily localize the changes and
> retrieve again
> > only necessary data.
>
> With RESTCONF, you can use etags and conditional requests. NETCONF
> lacks a similar generic mechanism to support caching. Instead of
> adding checksum everywhere into our data models, it seems a better
> solution would be to add something like etags to NETCONF. Hence, we
> reduced this to a single checksum which is needed as it is carried in
> the hello message.
>
> /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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Juergen Schoenwaelder]

On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote:
> On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
> >  
> > > > >  Sec. 1 - YANG library stability
> > > > > 
> > > > >  The text basically says that the YANG library information can
> > > > >  change at any time. This has been recently discussed but I
> > > > >  haven't seen any conclusion yet. I understand it is difficult to
> > > > >  enumerate all the situations when this information can change,
> > > > >  but it should also be emphasized that YL info is not just another
> > > > >  subtree of state data and that it should not change haphazardly.
> > > > 
> > > > I agree, but I think that YANG library's job is to report what the
> > > > server implements.  If the server dynamically changes its set of
> > > > loaded modules, then YL should adapt.
> > > > 
> > > > I welcome more discussion on this topic, but I don't think it has to
> > > > be documented in this draft.
> > > 
> > > What about this?
> > > 
> > > OLD
> > >The YANG library information can be different on every server and it
> > >can change at runtime or across a server reboot.  If a server
> > >implements multiple network management protocols to access the
> > >server's datastores, then each such protocol may have its own
> > >conceptual instantiation of the YANG library.
> > > 
> > > NEW
> > >The YANG library information represents a management API for a given
> > > server, 
> > >and should therefore be as stable as possible. The circumstances under
> > > which 
> > >this information can change are outside the scope of this document but 
> > > it
> > > is 
> > >advisable to consider potential impact on clients.
> > 
> > I like the old text because it tells the client clearly that this data
> > can change. And the statement has been in RFC 7895 in the exact same
> 
> My problem with the current text is that it seems to make no difference 
> between
> YANG library and any other state data.

The sentence starts with 'The YANG library information' and what
follows is all scoped to 'YANG library information'.
 
> > wording. If you want to add a statement that servers should not change
> > the YANG library without reason I could live with that but any attempt
> > to write text that makes the server somewhat guilty when a client is
> 
> Not guilty but careful. There is no requirement that clients check YANG 
> library
> between every two operations, and notifications are optional.


So let me try to make an alternate proposal. (I only added the second
sentence.)

NEW:

   The YANG library information can be different on every server and
   it can change at runtime or across a server reboot. Servers may
   schedule YANG library changes in way that minimizes the impact on
   active clients. If a server implements multiple network management
   protocols to access the server's datastores, then each such
   protocol may have its own conceptual instantiation of the YANG
   library.
 
> > not prepared to handle a YANG library change is IMHO a fundamental
> > change from what RFC 7895 said.
> > 
> > > > >  It is like with database schemas, REST APIs and the like. Of
> > > > >  course, these can change as well, but everybody has to understand
> > > > >  that doing so means transition problems, broken clients etc.
> > > > > 
> > > > >  For this reason, it might be useful to set YL and schema mount
> > > > >  data aside and call them metadata or schema information - even if
> > > > >  we continue modelling them with YANG.
> > > > 
> > > > Do you have some concrete proposal for where to introduce this term?
> > > 
> > > In RESTCONF it could be a separate well-known resource outside all
> > > datastores.
> > 
> > Putting the data into a different place does not change the impact of
> > the data changing. So I do not understand which problem introducing
> > yet another datastore solves.
> 
> Nothing except emphasizing the difference between data and metadata, which is
> IMO an important one.

So its a different topic - one that we closed before I thought.
 
> > > > >  Sec. 4 - checksum
> > > > > 
> > > > >  I think it would be very useful (even if not immediately) to
> > > > >  standardize the procedure for computing the checksum. What I
> > > > >  envision are systems that construct and process YANG schemas
> > > > >  (such as the YANG Catalog). They could benefit from having a
> > > > >  universal hash string as a characteristic of any particular
> > > > >  schema. Just consider how useful the universal hashes are e.g. in
> > > > >  git.
> > > > 
> > > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > > not needed immediately for this document.
> > > 
> > > Checksums are mandatory, so every implementation has to invent some 
> > > scheme.
> > > 
> > > Actually, it 

Re: [netmod] [Netconf] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Kent Watsen]

[removing netconf]


On 2/12/18, 12:20 PM, "Netconf on behalf of Kent Watsen" 
 on behalf of 
kwat...@juniper.net> wrote:

Hi Balazs,

I'm unclear about the scope of the problem.  Is it limited to server 
capabilities?It seems that the idea is to move from having a stateful 
connection to a live server to having a way to pass the equivalent state even 
when not connected to the server.

Related, but probably not what you're angling for, I've been having issues with 
validating RESTCONF examples.  The issue is that the RESTCONF documents are 
context specific.  For instance, GET /widgets/ returns a document that might 
have an outermost element called "widgets", whereas GET /widgets/widget=foo 
returns a document that might have an outermost element called "widget".   In 
order to validate the second document, my code first wraps the "widget" element 
with a "widgets" element, and then the validation tools work.

Perhaps a more generalized instance data mechanism could include where in the 
tree the data is situated?   For example, it would be helpful if an action's 
instance data could provide more context (e.g., the input/output documents 
could indicate the name of the action, the object that the action was invoked 
on, etc.).

Generally, there is some state being held by the protocols that complicates 
examining instance data outside of the protocol, as extra bits of state need to 
be passed around separately.  It would be nice if the documents were (or at 
least could be) more self-contained.

Kent // contributor


On 2/8/18, 4:17 AM, "netmod on behalf of Balazs Lengyel" 
 on behalf of 
balazs.leng...@ericsson.com> wrote:


Hello,

With Benoit I prepared a draft about how to document and use YANG defined 
instance data. It could be useful for documenting  server capabilities or 
preloading data defined in implementation time and probably for other purposes 
as well.

regards Balazs

 Forwarded Message 
Subject:

New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

Date:

Wed, 7 Feb 2018 09:28:50 -0800

From:

internet-dra...@ietf.org

To:

Benoit Claise , Balazs Lengyel 




A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt

has been successfully submitted by Balazs Lengyel and posted to the

IETF repository.



Name:  draft-lengyel-netmod-yang-instance-data

Revision:  00

Title: YANG Instance Data Files and their use for Documenting Server 
Capabilities

Document date: 2018-02-06

Group: Individual Submission

Pages: 10

URL:
https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/

Htmlized:   
https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00





Abstract:

   This document specifies a standard file format for YANG instance

   data, that is data that could be stored in a datastore and whose

   syntax and semantics is defined by YANG models.  Instance data files

   can be used to provide information that is defined in design time.

   There is a need to document Server capabilities (which are often

   specified in design time), which should be done using instance data

   files.

Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Kent Watsen]

Hi Balazs,

I'm unclear about the scope of the problem.  Is it limited to server 
capabilities?It seems that the idea is to move from having a stateful 
connection to a live server to having a way to pass the equivalent state even 
when not connected to the server.

Related, but probably not what you're angling for, I've been having issues with 
validating RESTCONF examples.  The issue is that the RESTCONF documents are 
context specific.  For instance, GET /widgets/ returns a document that might 
have an outermost element called "widgets", whereas GET /widgets/widget=foo 
returns a document that might have an outermost element called "widget".   In 
order to validate the second document, my code first wraps the "widget" element 
with a "widgets" element, and then the validation tools work.

Perhaps a more generalized instance data mechanism could include where in the 
tree the data is situated?   For example, it would be helpful if an action's 
instance data could provide more context (e.g., the input/output documents 
could indicate the name of the action, the object that the action was invoked 
on, etc.).

Generally, there is some state being held by the protocols that complicates 
examining instance data outside of the protocol, as extra bits of state need to 
be passed around separately.  It would be nice if the documents were (or at 
least could be) more self-contained.

Kent // contributor


On 2/8/18, 4:17 AM, "netmod on behalf of Balazs Lengyel" 
 on behalf of 
balazs.leng...@ericsson.com> wrote:


Hello,

With Benoit I prepared a draft about how to document and use YANG defined 
instance data. It could be useful for documenting  server capabilities or 
preloading data defined in implementation time and probably for other purposes 
as well.

regards Balazs

 Forwarded Message 
Subject:

New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

Date:

Wed, 7 Feb 2018 09:28:50 -0800

From:

internet-dra...@ietf.org

To:

Benoit Claise , Balazs Lengyel 




A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt

has been successfully submitted by Balazs Lengyel and posted to the

IETF repository.



Name:  draft-lengyel-netmod-yang-instance-data

Revision:  00

Title: YANG Instance Data Files and their use for Documenting Server 
Capabilities

Document date: 2018-02-06

Group: Individual Submission

Pages: 10

URL:
https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/

Htmlized:   
https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00





Abstract:

   This document specifies a standard file format for YANG instance

   data, that is data that could be stored in a datastore and whose

   syntax and semantics is defined by YANG models.  Instance data files

   can be used to provide information that is defined in design time.

   There is a need to document Server capabilities (which are often

   specified in design time), which should be done using instance data

   files.









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



--

Balazs Lengyel

[netmod] Protocol Action: 'YANG Tree Diagrams' to Best Current Practice (draft-ietf-netmod-yang-tree-diagrams-06.txt)

[The IESG]

The IESG has approved the following document:
- 'YANG Tree Diagrams'
  (draft-ietf-netmod-yang-tree-diagrams-06.txt) as Best Current Practice

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/




Technical Summary

   This document captures the current syntax used in YANG module Tree
   Diagrams.  The purpose of the document is to provide a single
   location for this definition.  This syntax may be updated from time
   to time based on the evolution of the YANG language.

Working Group Summary

   Yang tree diagrams are perhaps unusually for yang not 
   intended specifically to be machine readable, but rather  
   to display with  maximum legibility spinlified graphical 
   representations of modules. the dicussion that led to the 
   current formulation is therefore somewhat unusual territory
   for netmod. Nevertheless, the current approach has broad
   working-group support.

Document Quality

   There are known implementations of yang tree-diagram 
   rendering which produce results consistent with this document.

Personnel

   Joel Jaeggli is the document shepherd. 
   Benoit Claise is the responsible area director.

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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

[Alex Campbell]

Hi,

Perhaps not directly relevant, but the following sentence stuck out to me:

> Why not use the syslog/TLS specification, with the security features 
> administratively turned off within secure environments?

I was under the impression that the IETF tries to ensure that TLS security is 
not possible to turn off.
The assumption within the people working on TLS is that if you don't want 
security, you won't be using TLS.


I can think of two main reasons why syslog/TLS might not be desirable
- it adds administrative overhead - now you have to upload a certificate to 
every device that can send log messages (embedded devices don't use the Web's 
PKI).
- it adds runtime overhead - while general purpose devices these days are 
plenty fast to handle TLS, embedded devices may not be.


If TCP support is removed from the syslog model, then Aviat will most likely 
add it back as a vendor-specific extension, when we adopt this model.
I see the model is easily extensible with new transports so this will not be a 
problem - the only question is whether the extension should be standardized.
A quick Google search shows me that (at least some) Cisco and Juniper devices 
do support syslog/TCP, but it isn't widely used compared to UDP.


Alex


From: netmod  on behalf of Kent Watsen 

Sent: Saturday, 10 February 2018 5:42 a.m.
To: t.petch; Clyde Wildes (cwildes); netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Thank you, Tom.  That's an interesting bit of history there.  Of course, you 
would know, as I see you listed in the Acknowledgments section in RFC 6587.  
David Harrington's points are very compelling.

The chairs want to get this draft to Benoit before he steps down.  But looking 
at the draft right now, I can see that it is a very easy fix to remove the TCP 
transport layer support entirely, not much more than just moving the reference 
to Informative.

So, yes, let's bin it.

FWIW, I asked before if it were important to anyone, giving them a chance to 
speak up first.  But now, given how easy I see the fix is, that we should 
remove it without waiting for an answer.  If it is important to someone, let 
them speak up now.

Clyde, please let this be the update you plan to post today.

Thanks,
Kent // all hats


= original message =

Kent

The TCP syslog started out as Standards Track, after the syslog WG had
concluded, but David Harrington objected, as the extract below shows,
that it would never pass the IESG; and so it became Informational.

Further, the author, in 2013, described it as

"there is also historic RFC6587 on industry standard plain tcp, but this
is just for interoperating with legacy systems, not for new
implementation. It is strongly discouraged to use that in new systems.
"

Bin it IMHO.

Tom Petch
==


Many of the changes were made at my request.
I believe the document as written would not have made it through IESG
approval.

1) the IETF has defined a standard syslog; how to make your legacy
proprietary version work is not an IETF problem.

2) the syslog WG was created to develop a secure syslog solution with
secure transport and signing capability.
How to make your legacy proprietary version work over non-secure
transport is not an IETF problem.

3) Publishing this as a proposed standard seems to violate BCP 61.
syslog/tls already provides "strong security" over tcp, so syslog/tcp
is not needed to meet IETF goals. Under what
circumstances is it **desirable** to use this specification (with no
strong security available) in the Internet? Why not use the syslog/TLS

specification, with the security features administratively turned off
within secure environments?
You cannot justify implementing this by saying things like
"syslog/TLS is required and this is optional", and not explain WHY
this
additional non-bcp61-compliant specification is needed.

4) The aim of this IETF specification should be to document "how TCP
MAY be used as a
transport for standardized syslog", when the standard secure transport
may not apply.
(But I expect serious pushback from the IESG on this; see #3)
Because this might have to work with legacy deployments, we also
include as an appendix
"how to correlate the legacy and standard usages."

5) RFC3164 is just a survey, not a specification.

6) RFC2119 language needed to be cleaned up.

David Harrington
Director, IETF Transport Area
ietf...@comcast.net (preferred for ietf)
dbharring...@huaweisymantec.com
+1 603 828 1401 (cell)

> -Original Message-
> From: syslog-boun...@ietf.org
> [mailto:syslog-boun...@ietf.org] On Behalf Of t.petch
> Sent: Tuesday, November 02, 2010 1:02 AM
>
> Chris
>
> I had not noticed before but this seems to have changed
> direction during the
> summer; Informational not Standards Track, and stressing
> byte-counting more,
> byte-stuffing less.
>
> I do find it less clear.  I 

Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Ladislav Lhotka]

On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
>  
> > > >  Sec. 1 - YANG library stability
> > > > 
> > > >  The text basically says that the YANG library information can
> > > >  change at any time. This has been recently discussed but I
> > > >  haven't seen any conclusion yet. I understand it is difficult to
> > > >  enumerate all the situations when this information can change,
> > > >  but it should also be emphasized that YL info is not just another
> > > >  subtree of state data and that it should not change haphazardly.
> > > 
> > > I agree, but I think that YANG library's job is to report what the
> > > server implements.  If the server dynamically changes its set of
> > > loaded modules, then YL should adapt.
> > > 
> > > I welcome more discussion on this topic, but I don't think it has to
> > > be documented in this draft.
> > 
> > What about this?
> > 
> > OLD
> >The YANG library information can be different on every server and it
> >can change at runtime or across a server reboot.  If a server
> >implements multiple network management protocols to access the
> >server's datastores, then each such protocol may have its own
> >conceptual instantiation of the YANG library.
> > 
> > NEW
> >The YANG library information represents a management API for a given
> > server, 
> >and should therefore be as stable as possible. The circumstances under
> > which 
> >this information can change are outside the scope of this document but it
> > is 
> >advisable to consider potential impact on clients.
> 
> I like the old text because it tells the client clearly that this data
> can change. And the statement has been in RFC 7895 in the exact same

My problem with the current text is that it seems to make no difference between
YANG library and any other state data.

> wording. If you want to add a statement that servers should not change
> the YANG library without reason I could live with that but any attempt
> to write text that makes the server somewhat guilty when a client is

Not guilty but careful. There is no requirement that clients check YANG library
between every two operations, and notifications are optional.

> not prepared to handle a YANG library change is IMHO a fundamental
> change from what RFC 7895 said.
> 
> > > >  It is like with database schemas, REST APIs and the like. Of
> > > >  course, these can change as well, but everybody has to understand
> > > >  that doing so means transition problems, broken clients etc.
> > > > 
> > > >  For this reason, it might be useful to set YL and schema mount
> > > >  data aside and call them metadata or schema information - even if
> > > >  we continue modelling them with YANG.
> > > 
> > > Do you have some concrete proposal for where to introduce this term?
> > 
> > In RESTCONF it could be a separate well-known resource outside all
> > datastores.
> 
> Putting the data into a different place does not change the impact of
> the data changing. So I do not understand which problem introducing
> yet another datastore solves.

Nothing except emphasizing the difference between data and metadata, which is
IMO an important one.

> 
> > > >  Sec. 4 - checksum
> > > > 
> > > >  I think it would be very useful (even if not immediately) to
> > > >  standardize the procedure for computing the checksum. What I
> > > >  envision are systems that construct and process YANG schemas
> > > >  (such as the YANG Catalog). They could benefit from having a
> > > >  universal hash string as a characteristic of any particular
> > > >  schema. Just consider how useful the universal hashes are e.g. in
> > > >  git.
> > > 
> > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > not needed immediately for this document.
> > 
> > Checksums are mandatory, so every implementation has to invent some scheme.
> > 
> > Actually, it might be useful to have checksums also on module-sets, schemas
> > and
> > datastores so that the client can easily localize the changes and retrieve
> > again
> > only necessary data.
> 
> With RESTCONF, you can use etags and conditional requests. NETCONF
> lacks a similar generic mechanism to support caching. Instead of
> adding checksum everywhere into our data models, it seems a better
> solution would be to add something like etags to NETCONF. Hence, we
> reduced this to a single checksum which is needed as it is carried in
> the hello message.

Etags work, but my point here is to have the checksum as a globally unique
identifier of a given data model, schema or module set. For example, it would
allow for checking that multiple servers use the same data model.

Lada

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

___
netmod mailing list
netmod@ietf.org

Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Juergen Schoenwaelder]

On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
 
> > >  Sec. 1 - YANG library stability
> > > 
> > >  The text basically says that the YANG library information can
> > >  change at any time. This has been recently discussed but I
> > >  haven't seen any conclusion yet. I understand it is difficult to
> > >  enumerate all the situations when this information can change,
> > >  but it should also be emphasized that YL info is not just another
> > >  subtree of state data and that it should not change haphazardly.
> > 
> > I agree, but I think that YANG library's job is to report what the
> > server implements.  If the server dynamically changes its set of
> > loaded modules, then YL should adapt.
> > 
> > I welcome more discussion on this topic, but I don't think it has to
> > be documented in this draft.
> 
> What about this?
> 
> OLD
>The YANG library information can be different on every server and it
>can change at runtime or across a server reboot.  If a server
>implements multiple network management protocols to access the
>server's datastores, then each such protocol may have its own
>conceptual instantiation of the YANG library.
> 
> NEW
>The YANG library information represents a management API for a given 
> server, 
>and should therefore be as stable as possible. The circumstances under 
> which 
>this information can change are outside the scope of this document but it 
> is 
>advisable to consider potential impact on clients.

I like the old text because it tells the client clearly that this data
can change. And the statement has been in RFC 7895 in the exact same
wording. If you want to add a statement that servers should not change
the YANG library without reason I could live with that but any attempt
to write text that makes the server somewhat guilty when a client is
not prepared to handle a YANG library change is IMHO a fundamental
change from what RFC 7895 said.

> > >  It is like with database schemas, REST APIs and the like. Of
> > >  course, these can change as well, but everybody has to understand
> > >  that doing so means transition problems, broken clients etc.
> > > 
> > >  For this reason, it might be useful to set YL and schema mount
> > >  data aside and call them metadata or schema information - even if
> > >  we continue modelling them with YANG.
> > 
> > Do you have some concrete proposal for where to introduce this term?
> 
> In RESTCONF it could be a separate well-known resource outside all datastores.

Putting the data into a different place does not change the impact of
the data changing. So I do not understand which problem introducing
yet another datastore solves.

> > >  Sec. 4 - checksum
> > > 
> > >  I think it would be very useful (even if not immediately) to
> > >  standardize the procedure for computing the checksum. What I
> > >  envision are systems that construct and process YANG schemas
> > >  (such as the YANG Catalog). They could benefit from having a
> > >  universal hash string as a characteristic of any particular
> > >  schema. Just consider how useful the universal hashes are e.g. in
> > >  git.
> > 
> > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > not needed immediately for this document.
> 
> Checksums are mandatory, so every implementation has to invent some scheme.
> 
> Actually, it might be useful to have checksums also on module-sets, schemas 
> and
> datastores so that the client can easily localize the changes and retrieve 
> again
> only necessary data.

With RESTCONF, you can use etags and conditional requests. NETCONF
lacks a similar generic mechanism to support caching. Instead of
adding checksum everywhere into our data models, it seems a better
solution would be to add something like etags to NETCONF. Hence, we
reduced this to a single checksum which is needed as it is carried in
the hello message.

/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] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Juergen Schoenwaelder]

Since you already have several attributes for the instance-data
element (ida:instance-data-set, ida:revision, ida:description,
ida:contact), adding ida:datastore may do the work (but not on a per
node basis, it needs to be restricted to be used only on the
instance-data element.

Note that some of these attributes are not well defined. I do not
understand "The annotation SHALL only be used on the top level 
element in RFC  defined YANG Instance Data files." Perhaps you
want to restrict them to be only used on instance-data? (Which
namespace does this live in if any?) It is kind of unclear why you
define the attributes listed above in YANG but you do not define
instance-data itself in YANG. It seems you either define everything
about this format in YANG or nothing. But yes, this is a -00 so I
assume all of this can be improved.

/js

On Mon, Feb 12, 2018 at 03:09:08PM +0100, Balazs Lengyel wrote:
> Hello Jurgen,
> 
> What would be your preference? How should we specify datastore? Could you
> please provide some description.
> 
> regards Balazs
> 
> 
> On 2/12/2018 2:15 PM, Juergen Schoenwaelder wrote:
> > On Mon, Feb 12, 2018 at 01:51:30PM +0100, Balazs Lengyel wrote:
> > > Hello Jurgen,
> > > OK, I will add some text about:
> > > 
> > > datastore selection, default being running/operational for config 
> > > true/false
> > > data, mentioning NMDA.
> > > 
> > Once again, this is ambiguous.
> > 
> > > I will add a ida:datastore metadata that can placed on any any data-node 
> > > (?)
> > On any data node???
> 
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 
> ___
> 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] LL review of draft-ietf-netconf-rfc7895bis-04

[Ladislav Lhotka]

On Mon, 2018-02-12 at 13:02 +0100, Martin Bjorklund wrote:
> Hi,
> 
> Thank you for this review.  Comments inline.
> 
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > here is my review of the rfc7895bis document:
> > 
> > *** General comments
> > - This revision is a significant improvement necessary for
> >   supporting NMDA. However, it is also flexible enough in that it
> >   allows for implementing the NMDA rules in an effective way but
> >   doesn't preclude the use of other datastores and datastore
> >   architectures.
> > 
> > - Another benefit is that the new YANG library schema can be
> >   easily integrated with schema mount information.
> > 
> > *** Specific comments
> > 
> >  Sec. 1 - backward compatibility
> > 
> >  Given that the old YANG library schema is carried over as a
> >  deprecated subtree, how can a server implementor actually cater
> >  for backward compatibility of e.g. RESTCONF clients supporting
> >  only RFC 8040?  Could the same YANG modules that comprise NMDA
> >  datastore schemas be advertized also via the old YANG library? Or
> >  is it necessary to also have pre-NMDA versions of all modules?
> > 
> >  Some more explanation might be useful here.
> 
> The text says:
> 
>   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.
> 
> Do you think that more guidance is needed?
> My opinion is that a server that wasnt to be backwards compatible
> probably advertise exactly what it used to advertise (in
> /modules-state), even if new NMDA-compatible models are added and
> advertised in /yang-library for new clients.
> 
> In general it is of course not possible to advertise everything that
> is availabile in /yang-library also in /modules-state - if this was
> possible we wouldn't have done YLbis.

Yes, I guess the question here is what "backward-compatible" means (given that
it is a SHOULD). One interpretation could be that it is sufficient to make sure
that, e.g., all resources required by RFC 8040 are present. So a lazy
implementor could just use an (almost) empty "modules-state" list. Does this
qualify as backward-compatible?

> 
> I don't think this document should provide recommendations on whether
> to implement pre-NMDA versions or not; this will be up to each server
> implementor to decide.

So it means that (in RESTCONF) /modules-state is bound to the legacy resource

{+restconf}/data

and /yang-library to the new datastore resources as defined in draft-ietf-
netconf-nmda-restconf, and these two are basically unrelated?

> >  Sec. 1 - YANG library stability
> > 
> >  The text basically says that the YANG library information can
> >  change at any time. This has been recently discussed but I
> >  haven't seen any conclusion yet. I understand it is difficult to
> >  enumerate all the situations when this information can change,
> >  but it should also be emphasized that YL info is not just another
> >  subtree of state data and that it should not change haphazardly.
> 
> I agree, but I think that YANG library's job is to report what the
> server implements.  If the server dynamically changes its set of
> loaded modules, then YL should adapt.
> 
> I welcome more discussion on this topic, but I don't think it has to
> be documented in this draft.

What about this?

OLD
   The YANG library information can be different on every server and it
   can change at runtime or across a server reboot.  If a server
   implements multiple network management protocols to access the
   server's datastores, then each such protocol may have its own
   conceptual instantiation of the YANG library.

NEW
   The YANG library information represents a management API for a given server, 
   and should therefore be as stable as possible. The circumstances under which 
   this information can change are outside the scope of this document but it is 
   advisable to consider potential impact on clients.

> 
> >  It is like with database schemas, REST APIs and the like. Of
> >  course, these can change as well, but everybody has to understand
> >  that doing so means transition problems, broken clients etc.
> > 
> >  For this reason, it might be useful to set YL and schema mount
> >  data aside and call them metadata or schema information - even if
> >  we continue modelling them with YANG.
> 
> Do you have some concrete proposal for where to introduce this term?

In RESTCONF it could be a separate well-known resource outside all datastores.

> 
> >  Sec. 3 - semantic versioning
> > 
> >  Some placeholders for future inclusion of semantic versions in
> >  YANG library information might be useful. To this end, I would
> >  suggest to introduce a new choice node and make 

Re: [netmod] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Balazs Lengyel]

Hello Jurgen,

What would be your preference? How should we specify datastore? Could 
you please provide some description.


regards Balazs


On 2/12/2018 2:15 PM, Juergen Schoenwaelder wrote:

On Mon, Feb 12, 2018 at 01:51:30PM +0100, Balazs Lengyel wrote:

Hello Jurgen,
OK, I will add some text about:

datastore selection, default being running/operational for config true/false
data, mentioning NMDA.


Once again, this is ambiguous.


I will add a ida:datastore metadata that can placed on any any data-node (?)

On any data node???


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Juergen Schoenwaelder]

On Mon, Feb 12, 2018 at 01:51:30PM +0100, Balazs Lengyel wrote:
> Hello Jurgen,
> OK, I will add some text about:
> 
> datastore selection, default being running/operational for config true/false
> data, mentioning NMDA.
>

Once again, this is ambiguous.

> I will add a ida:datastore metadata that can placed on any any data-node (?)

On any data node???

/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] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Balazs Lengyel]

Hello Jurgen,
OK, I will add some text about:

datastore selection, default being running/operational for config 
true/false data, mentioning NMDA.


I will add a ida:datastore metadata that can placed on any any data-node (?)

A section about a use case of having examples in documents

regards Balazs


On 2/12/2018 12:40 PM, Juergen Schoenwaelder wrote:

On Mon, Feb 12, 2018 at 12:14:11PM +0100, Balazs Lengyel wrote:

BALAZS:  Sorry but where is the guessing?

If there is no config false instance, how do I decide?


The YANG model explicitly states whether data is config=false or true.
For config=true data it is always the running datastore
For config=false data it only depends on the NMDA support. E.g. the yanglib
model will be used on new and old servers too.
Also it is an explicit aim of the draft that we should allow mixing of
config=true and config=false data in the same instance data set.

Would you prefer that I add as metadata "ida:config-datastore=XXX" ? Here
XXX could be running or some dynamic (e.g. SDN) with default being running.
Or do you see any use case for documenting/loading candidate, startup,
intended or operational data for config=true ? If so please describe.

Config=false data it will always go into operational or "other" in case of a
preNMDA server; so I don't see a need for any extra selector here.

I see a use case of having examples in documents (which likely are not
even complete) and I think tools prefer to know upfront which
datastore the example belongs to without first doing complex
processing.

/js



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04

[Martin Bjorklund]

Hi,

Thank you for this review.  Comments inline.

Ladislav Lhotka  wrote:
> Hi,
> 
> here is my review of the rfc7895bis document:
> 
> *** General comments
> - This revision is a significant improvement necessary for
>   supporting NMDA. However, it is also flexible enough in that it
>   allows for implementing the NMDA rules in an effective way but
>   doesn't preclude the use of other datastores and datastore
>   architectures.
> 
> - Another benefit is that the new YANG library schema can be
>   easily integrated with schema mount information.
> 
> *** Specific comments
> 
>  Sec. 1 - backward compatibility
> 
>  Given that the old YANG library schema is carried over as a
>  deprecated subtree, how can a server implementor actually cater
>  for backward compatibility of e.g. RESTCONF clients supporting
>  only RFC 8040?  Could the same YANG modules that comprise NMDA
>  datastore schemas be advertized also via the old YANG library? Or
>  is it necessary to also have pre-NMDA versions of all modules?
> 
>  Some more explanation might be useful here.

The text says:

  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.

Do you think that more guidance is needed?

My opinion is that a server that wasnt to be backwards compatible
probably advertise exactly what it used to advertise (in
/modules-state), even if new NMDA-compatible models are added and
advertised in /yang-library for new clients.

In general it is of course not possible to advertise everything that
is availabile in /yang-library also in /modules-state - if this was
possible we wouldn't have done YLbis.

I don't think this document should provide recommendations on whether
to implement pre-NMDA versions or not; this will be up to each server
implementor to decide.

>  Sec. 1 - YANG library stability
> 
>  The text basically says that the YANG library information can
>  change at any time. This has been recently discussed but I
>  haven't seen any conclusion yet. I understand it is difficult to
>  enumerate all the situations when this information can change,
>  but it should also be emphasized that YL info is not just another
>  subtree of state data and that it should not change haphazardly.

I agree, but I think that YANG library's job is to report what the
server implements.  If the server dynamically changes its set of
loaded modules, then YL should adapt.

I welcome more discussion on this topic, but I don't think it has to
be documented in this draft.

>  It is like with database schemas, REST APIs and the like. Of
>  course, these can change as well, but everybody has to understand
>  that doing so means transition problems, broken clients etc.
> 
>  For this reason, it might be useful to set YL and schema mount
>  data aside and call them metadata or schema information - even if
>  we continue modelling them with YANG.

Do you have some concrete proposal for where to introduce this term?

>  Sec. 3 - semantic versioning
> 
>  Some placeholders for future inclusion of semantic versions in
>  YANG library information might be useful. To this end, I would
>  suggest to introduce a new choice node and make "revision" (or,
>  even better, "revision-date") its only case. This way, other
>  versioning schemes such as semver could be easily added via
>  augmentation.

When revision is used as a list key, we can't have a choice.

And when it is not a key, it is an optional leaf, so adding a 'semver'
optional leaf in the future is also ok.

The proposal I have seen adds semver as an addition to revision, so
using a choice would not be correct in this case.


>  Sec. 4 - checksum
> 
>  I think it would be very useful (even if not immediately) to
>  standardize the procedure for computing the checksum. What I
>  envision are systems that construct and process YANG schemas
>  (such as the YANG Catalog). They could benefit from having a
>  universal hash string as a characteristic of any particular
>  schema. Just consider how useful the universal hashes are e.g. in
>  git.

Ok.  It would be interesting to see such a scheme.  But I agree it is
not needed immediately for this document.

>  Nits
> 
>  - sec 1. paragraph 2: s/informaton/information/

Fixed.


/martin


> 
> Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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

Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Juergen Schoenwaelder]

On Mon, Feb 12, 2018 at 12:14:11PM +0100, Balazs Lengyel wrote:
> 
> BALAZS:  Sorry but where is the guessing?

If there is no config false instance, how do I decide?

> The YANG model explicitly states whether data is config=false or true.
> For config=true data it is always the running datastore
> For config=false data it only depends on the NMDA support. E.g. the yanglib
> model will be used on new and old servers too.
> Also it is an explicit aim of the draft that we should allow mixing of
> config=true and config=false data in the same instance data set.
> 
> Would you prefer that I add as metadata "ida:config-datastore=XXX" ? Here
> XXX could be running or some dynamic (e.g. SDN) with default being running.
> Or do you see any use case for documenting/loading candidate, startup,
> intended or operational data for config=true ? If so please describe.
> 
> Config=false data it will always go into operational or "other" in case of a
> preNMDA server; so I don't see a need for any extra selector here.

I see a use case of having examples in documents (which likely are not
even complete) and I think tools prefer to know upfront which
datastore the example belongs to without first doing complex
processing.

/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] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Balazs Lengyel]

On 2/12/2018 11:47 AM, Juergen Schoenwaelder wrote:

On Mon, Feb 12, 2018 at 10:49:48AM +0100, Balazs Lengyel wrote:

Hello Jurgen,

IMHO once we know whether the data is config=false or true and know the
datastores the server supports the datastore the instance data is relevant
to is fixed. One exception is the possible loading of dynamic datastores.
However as I do not have a use-case for these and we do not have any
dynamic datastores defined, IMHO we can leave the usage of these
datastores out of scope. If I added the following paragraphs would that
help?

"If the instance data specifies config false (state data) and the server
support the operational datastore, the instance data documents the
operational datastore. If  the operational datastore is not supported the
data documents additional state data that is stored outside the
configuration datastores. The instance data MAY be used to load the
relevant datastore or it MAY just be used to document its content.

Having to guess the datastore from the instance data feels wrong to
me. It is not robust.


If the instance data specifies config true (configuration data)  the
instance data documents the running datastore.  The instance data MAY be
used to load the running  datastore or it MAY just be used to document its
content. While the instance data format MAY be used to load other e.g.
dynamic datastores that is out of scope for this specification."

Also further clarification may be provided for each use-case in the
relevant document.

Why not make the data format robust? What speaks against indicating
explicitly to which datastore data belongs?

/js

BALAZS:  Sorry but where is the guessing?
The YANG model explicitly states whether data is config=false or true.
For config=true data it is always the running datastore
For config=false data it only depends on the NMDA support. E.g. the 
yanglib model will be used on new and old servers too.
Also it is an explicit aim of the draft that we should allow mixing of 
config=true and config=false data in the same instance data set.


Would you prefer that I add as metadata "ida:config-datastore=XXX" ? 
Here XXX could be running or some dynamic (e.g. SDN) with default being 
running. Or do you see any use case for documenting/loading candidate, 
startup, intended or operational data for config=true ? If so please 
describe.


Config=false data it will always go into operational or "other" in case 
of a preNMDA server; so I don't see a need for any extra selector here.


regards Balazs

--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Juergen Schoenwaelder]

On Mon, Feb 12, 2018 at 10:49:48AM +0100, Balazs Lengyel wrote:
>Hello Jurgen,
> 
>IMHO once we know whether the data is config=false or true and know the
>datastores the server supports the datastore the instance data is relevant
>to is fixed. One exception is the possible loading of dynamic datastores.
>However as I do not have a use-case for these and we do not have any
>dynamic datastores defined, IMHO we can leave the usage of these
>datastores out of scope. If I added the following paragraphs would that
>help?
> 
>"If the instance data specifies config false (state data) and the server
>support the operational datastore, the instance data documents the
>operational datastore. If  the operational datastore is not supported the
>data documents additional state data that is stored outside the
>configuration datastores. The instance data MAY be used to load the
>relevant datastore or it MAY just be used to document its content.

Having to guess the datastore from the instance data feels wrong to
me. It is not robust.

>If the instance data specifies config true (configuration data)  the
>instance data documents the running datastore.  The instance data MAY be
>used to load the running  datastore or it MAY just be used to document its
>content. While the instance data format MAY be used to load other e.g.
>dynamic datastores that is out of scope for this specification."
> 
>Also further clarification may be provided for each use-case in the
>relevant document.

Why not make the data format robust? What speaks against indicating
explicitly to which datastore data belongs?

/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] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[Balazs Lengyel]

  
  
Hello Jurgen,
IMHO once we know whether the data is config=false or true and
  know the datastores the server supports the datastore the instance
  data is relevant to is fixed. One exception is the possible
  loading of dynamic datastores. However as I do not have a use-case
  for these and we do not have any dynamic datastores defined, IMHO
  we can leave the usage of these datastores out of scope. If I
  added the following paragraphs would that help?
"If the instance data specifies config false (state data) and
the server support the operational datastore, the instance data
documents the operational datastore. If  the operational
datastore is not supported the data documents additional state
data that is stored outside the configuration datastores. The
instance data MAY be used to load the relevant datastore or it
MAY just be used to document its content.
 If the instance data specifies config true
(configuration data)  the instance data documents the running
datastore.  The instance data MAY be used to load the running 
datastore or it MAY just be used to document its content. While
the instance data format MAY be used to load other e.g. dynamic
datastores that is out of scope for this specification."
Also further clarification may be provided for each use-case
in the relevant document. 

regards Balazs

On 2/9/2018 5:25 PM, Juergen
  Schoenwaelder wrote:


  How do I know which datastore the data belongs to? Would it not make
sense to carry that information inline? If we do not carry this
information inline, how is that information supposed to be provided
if for example this format is used to validate examples included in
documentation?

/js

On Fri, Feb 09, 2018 at 04:07:11PM +0100, Balazs Lengyel wrote:

  
Hello Jurgen,

I will gladly add NMDA to the draft. However could you please be more
specific. Which part of NMDA are you missing?
Is it the example of yanglib that you would like updated?

As the instance-data can be used to document and/or load    both config=true
and false data it is IMHO relevant to the candidate/running/operational
datastores. However whether it should be used to just document data or also
to load data, and how exactly such a load should be implemented  is out of
scope. And yes using one SW kit config=false data can be loaded from file
too.

regards Balazs


On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote:


  [Removing NETCONF since the I-D says -netmod-.]

I flipped through the I-D yesterday and I think a common format for
instance data trees should be NMDA aware these days.

/js

On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote:

  
Hello,

With Benoit I prepared a draft about how to document and use YANG defined
instance data. It could be useful for documenting  server capabilities or
preloading data defined in implementation time and probably for other
purposes as well.

regards Balazs

 Forwarded Message 

Subject: New Version Notification for
 draft-lengyel-netmod-yang-instance-data-00.txt
   Date: Wed, 7 Feb 2018 09:28:50 -0800
   From: [1]internet-dra...@ietf.org
 To: Benoit Claise [2], Balazs Lengyel
 [3]

  A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt
  has been successfully submitted by Balazs Lengyel and posted to the
  IETF repository.

  Name:   draft-lengyel-netmod-yang-instance-data
  Revision:   00
  Title:  YANG Instance Data Files and their use for Documenting Server Capabilities
  Document date:  2018-02-06
  Group:  Individual Submission
  Pages:  10
  URL:[4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt
  Status: [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/
  Htmlized:   [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00
  Htmlized:   [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00


  Abstract:
 This document specifies a standard file format for YANG instance
 data, that is data that could be stored in a datastore and whose
 syntax and semantics is defined by YANG models.  Instance data files
 can be used to provide information that is defined in design time.
 There is a need to document Server capabilities (which are often
 specified in design time), which should be done using instance data
 files.




  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


  --
  Balazs Lengyel   Ericsson Hungary