Subject: [netmod] About Yang 1.1 Y58, there have one suggested solution in draft-zheng-netmod-integrate-operations,please check and comments：//答复: netmod Digest, Vol 80, Issue 43

From: Zhengguangying <[email-masked]>
Date: Thu, 13 Nov 2014 21:39:29 +0000

About Yang 1.1 Y58, there have one suggested solution in draft-zheng-netmod-integrate-operations,please check and comments

https://datatracker.ietf.org/doc/draft-zheng-netmod-integrate-operations/

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年11月13日 10:01
收件人: [email-masked]
主题: netmod Digest, Vol 80, Issue 43

Send netmod mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/netmod
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of netmod digest..."

Today's Topics:

   1. Re: separate state and config (Juergen Schoenwaelder)
   2. Re: separate state and config (Martin Bjorklund)
   3. Re: VRFY :Y58: associate an actions with a data node
      (Juergen Schoenwaelder)
   4. Re: VRFY :Y58: associate an actions with a data node
      (Juergen Schoenwaelder)
   5. Re: IETF Syslog Model Flaw (Juergen Schoenwaelder)
   6. Re: separate state and config (Thomas D. Nadeau)

----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Nov 2014 20:20:03 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] separate state and config
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

On Thu, Nov 13, 2014 at 08:02:24PM +0100, Martin Bjorklund wrote:

> If you write something through RESTCONF, it immediately shows up in
> get-config(running) in NETCONF.

Out of curiosity: What happens if running is locked? I get a 409 Conflict HTTP error response?

/js

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

------------------------------

Message: 2
Date: Thu, 13 Nov 2014 20:24:44 +0100 (CET)
From: Martin Bjorklund <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] separate state and config
Message-ID: <[email-masked]>
Content-Type: Text/Plain; charset=us-ascii

Juergen Schoenwaelder <[email-masked]> wrote:
> On Thu, Nov 13, 2014 at 08:02:24PM +0100, Martin Bjorklund wrote:
> 
> > If you write something through RESTCONF, it immediately shows up in
> > get-config(running) in NETCONF.
> 
> Out of curiosity: What happens if running is locked? I get a 409 
> Conflict HTTP error response?

Yes, see section 6 in the draft, and the example in 6.1.

/martin

------------------------------

Message: 3
Date: Thu, 13 Nov 2014 20:38:22 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Andy Bierman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

On Thu, Nov 06, 2014 at 07:38:16AM -0800, Andy Bierman wrote:
> Hi,
> 
> OK, I thought Juergen meant the generic data wrapper, not the literal 
> <data> element wrapper.  That is fine.
> 
> But what about NACM?  We are the co-authors, and I think we are 
> willing to do the editing, but it is up to the IESG to charter and the 
> WG to do the work.
> 
> What about I2RS requirements for owner-based access-control?
> IMO NACM is applied first. Owner priority applies when the data 
> already exists (both clients have NACM permission).
> It is not clear if any changes to NACM are required to support I2RS.

We probably have to serialize work and NACM belongs to NETCONF, so we would have to take any update needed to NETCONF I think.

/js

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

------------------------------

Message: 4
Date: Thu, 13 Nov 2014 20:40:05 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Andy Bierman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Andy,

given Martin's clarification, are you find the proposed resolution of Y58?

/js

On Thu, Nov 06, 2014 at 07:38:16AM -0800, Andy Bierman wrote:
> Hi,
> 
> OK, I thought Juergen meant the generic data wrapper, not the literal 
> <data> element wrapper.  That is fine.
> 
> But what about NACM?  We are the co-authors, and I think we are 
> willing to do the editing, but it is up to the IESG to charter and the 
> WG to do the work.
> 
> What about I2RS requirements for owner-based access-control?
> IMO NACM is applied first. Owner priority applies when the data 
> already exists (both clients have NACM permission).
> It is not clear if any changes to NACM are required to support I2RS.
> 
> 
> Andy
> 
> 
> On Wed, Nov 5, 2014 at 6:55 AM, Martin Bjorklund <[email-masked]> wrote:
> > Andy Bierman <[email-masked]> wrote:
> >> On Wed, Nov 5, 2014 at 6:14 AM, Juergen Schoenwaelder 
> >> <[email-masked]> wrote:
> >> > The 2014-10-15 virtual interim meeting proposal is to use the 
> >> > encoding but to remove the data wrapper. In addition, issue Y36 
> >> > should be opened again, asking for proposals how to encode 
> >> > notifications associated with data nodes.
> >> >
> >>
> >>
> >> I do not remember that we agreed to remove the data wrapper 
> >> (meaning the instance information for the action).
> >
> > NOTE: this means that instead of doing:
> >
> >      <rpc message-id="101"
> >           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
> >           xmlns:yang="urn:ietf:params:xml:ns:yang:1">
> >         <yang:action>
> >             <data>
> >                 <server xmlns="http://example.net/server-farm">
> >                     <name>apache-1</name>
> >                     <reset>
> >                         <reset-at>2014-07-29T13:42Z</reset-at>
> >                     </reset>
> >                 </server>
> >             </data>
> >         </action>
> >      </rpc>
> >
> > we'd do:
> >
> >      <rpc message-id="101"
> >           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
> >           xmlns:yang="urn:ietf:params:xml:ns:yang:1">
> >         <yang:action>
> >           <server xmlns="http://example.net/server-farm">
> >             <name>apache-1</name>
> >             <reset>
> >               <reset-at>2014-07-29T13:42Z</reset-at>
> >             </reset>
> >           </server>
> >         </action>
> >      </rpc>
> >
> >
> >
> >
> > /martin

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

------------------------------

Message: 5
Date: Thu, 13 Nov 2014 20:45:32 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Clyde Wildes (cwildes)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] IETF Syslog Model Flaw
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

On Thu, Nov 13, 2014 at 07:01:14PM +0000, Clyde Wildes (cwildes) wrote:
> Juergen,
> 
> Thanks for your review.
> 
> One of the network element operating systems that I have been working 
> with requires prior knowledge of ip-type in order to configure remote access.
> If you feel strongly about this we can leave the model alone and 
> augment for the ip-type. Regarding mandatory: I agree that if we leave 
> it in, it should not be mandatory.

If this is not a common requirement, then I would prefer to leave it out. Things like rsyslogd etc. do not seem to require this.

That said, there should perhaps be a warning in the description clause that relying on DNS name resolution may cause some log messages to be lost. In order to reduce the likelihood of messages lost due to DNS resolution time, it may be a good idea to configure an IP address instead of a name.

/js

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

------------------------------

Message: 6
Date: Thu, 13 Nov 2014 09:51:50 -1000
From: "Thomas D. Nadeau" <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] separate state and config
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

	That is probably up to the "application" making the call.  It can just retry of course.

	--Tom

> On Nov 13, 2014:9:20 AM, at 9:20 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> On Thu, Nov 13, 2014 at 08:02:24PM +0100, Martin Bjorklund wrote:
> 
>> If you write something through RESTCONF, it immediately shows up in
>> get-config(running) in NETCONF.
> 
> Out of curiosity: What happens if running is locked? I get a 409 
> Conflict HTTP error response?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 

------------------------------

Subject: Digest Footer

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

------------------------------

End of netmod Digest, Vol 80, Issue 43
**************************************

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 14 Nov 2014 10:20:31 +0000

Hello,
Some comments on the draft:
We agree on the need for actions/operations embedded in the data model. We also agree on the access control benefits. (There are other as well), Most of the thing you want to achieve can be achieved by the current Y58 Action proposal.

General:
It is not just complex edits that need actions/RPCs.
a) operations where we do not want not store data: restart, ping, transfer-file, upgrade. Primary goal, as the other two can be done by edit-config/get
b) operations for complex edits
c) operations for complex read operations

IMO it is a bad idea to model actions/RPCs/methods to be strongly based on the edit-config, get-config operations. In our experience the use case a) is the MOST important. We in Ericsson discourage storing data by special operations, because it leads to other operational problems. 
Often actions have multiple input and output parameters, which is difficult to accommodate in edit/get operations
Even in your own example in chapter 4.2 you indicate basing you operation on edit-config, but you actually follow the RPC/Action  pattern:
- use the input statement for defining input, 
- the actual input includes parameters NOT found in the data nodes of the model just in the special method/action

It is not described anywhere what exactly "inheriting" from edit-config, get, get-config would mean? In your example you do not use anything from the edit-config options. It would be quite a bit of work to define it, impacting both YANG and Netconf.

Chapter 3.1
IMHO the most important use of actions/RPC is where you do not store data. In these case all these options are unneeded, or even confusing.
ARP data manipulation: as data is moved from one part of the server to another, many of the options are not meaningful: 
- operation if any is usually inherently defined by the action, can not be chosen 
- validate (if it was valid as dynamic data usually it must be valid as static data as well) 
If needed similar options can be redefined for an RPC/action.

Chapter 3.3
Don’t base actions/operations on edit-config/get-config. In our experience the most important use-case is the non-data handling actions: restart, backup, ping; not read and write.
It is never explained how to specify what is the scope of database manipulations. It would be complicated to define it. The base for access control has to be the location of the action/operation.

Chapter 4.2
Even though you define your method to inherit from edit-config, its definition is much more similar to an RPC method. Its input parameters are not part of the "normal" data model. 
Regards Balazs

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年11月13日 10:01
收件人: [email-masked]
主题: netmod Digest, Vol 80, Issue 43

Today's Topics:

Message: 1

/js

Message: 2

/martin

Message: 3

/js

Message: 4

Andy,

/js

Message: 5

/js

Message: 6

	--Tom

Subject: Digest Footer