Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Jun 2015 09:25:53 +0200

On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote:

> [...] So we need to find a common format for the "content" to
> accommodate different types of "target". what I can imagine is
> anyxml could be used. But seems it is not a good choice. Because
> based on RFC6020, it is not recommended to be used on configuration
> data.

Since you plan to augment a notification, this won't be config true
data (this is what the statement in RFC 6020 really hints at). See
also the definition of 'configuration data' in section 3 of RFC 6020.

/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/>

---

From: Mandy Liu <[email-masked]>
Date: Mon, 1 Jun 2015 07:48:51 +0000

Sorry, I don't get your point. But hopefully I addressed my question more clearly this time. 

The configuration change notification is generated when the NETCONF server detects that the <running> or <startup> configuration datastore has been changed by a management session. The notification summarizes the "edits" that have been detected. "  The structure of the "edit" is addressed in RFC6470 as below. What I want is to add the another leaf to address the "target" is changed to what. But because the "target" may be a container, a list, a leaf or a leaf-reference, etc. It could be any node of the tree. So a common format for addressing the "target" is changed to what is needed. 
list edit {
    leaf target {
        type instance-identifier;
       description
       .....
    }
    leaf operation {
        type nc:edit-operation-type;
       description
            .....
    }
}

Thanks,
Mandy
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 3:26 PM
To: Mandy Liu
Cc: [email-masked]; Kai Lin; Robert Ottinger; [email-masked]; Athanasios Kyparlis
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote:

> accommodate different types of "target". what I can imagine is anyxml 
> could be used. But seems it is not a good choice. Because based on 
> RFC6020, it is not recommended to be used on configuration data.

Since you plan to augment a notification, this won't be config true data (this is what the statement in RFC 6020 really hints at). See also the definition of 'configuration data' in section 3 of RFC 6020.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Jun 2015 11:54:56 +0200

Let me try to say it differently: Using anyxml in a notification does not
cause a conflict with this statement in section 7.10 of RFC 6020:

   Since the use of anyxml limits the manipulation of the content, it is
   RECOMMENDED that the "anyxml" statement not be used to represent
   configuration data.

Note that configuration data is defined as follows:

   o  configuration data: The set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

Notification content is not configuration data.

/js

---

From: Mandy Liu <[email-masked]>
Date: Tue, 2 Jun 2015 06:22:25 +0000

Ok, thanks! Got your point.
But here I want to use "data" to address the changed configuration data in the notification. Although "data" is in the notification, but because it is used to address the configuration data seems it still conflicts with the statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml" statement not be used to represent configuration data. "

list edit {
     leaf target {
     anyxml data;
 }

Regards,
Mandy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 5:55 PM
To: Mandy Liu
Cc: [email-masked]; Kai Lin; Robert Ottinger; [email-masked]; Athanasios Kyparlis
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

Let me try to say it differently: Using anyxml in a notification does not cause a conflict with this statement in section 7.10 of RFC 6020:

/js

On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > based on RFC6020, it is not recommended to be used on configuration data.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Jun 2015 08:47:44 +0200

But it is not the writable configuration data but more a copy of the
configuration data that got changed. Anyway, if you want to insist
that this is a violation of section 7.10 of RFC6020, then don't do
it. I do not believe it is a violation of section 7.10 of RFC6020.

/js

---

From: Mandy Liu <[email-masked]>
Date: Tue, 2 Jun 2015 07:18:22 +0000

I am not intent to insist that. I just want to make sure it won't violate RFC6020. I think you have convinced me by below sentence. Thanks for your support, Juergen!
- "But it is not the writable configuration data but more a copy of the configuration data that got changed."

Regards,
Mandy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2015 2:48 PM
To: Mandy Liu
Cc: [email-masked]; Kai Lin; Robert Ottinger; [email-masked]; Athanasios Kyparlis
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

But it is not the writable configuration data but more a copy of the configuration data that got changed. Anyway, if you want to insist that this is a violation of section 7.10 of RFC6020, then don't do it. I do not believe it is a violation of section 7.10 of RFC6020.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Jun 2015 09:04:41 -0700

Hi,

There are (at least) 2 technical issues you should consider, in case you are
wondering why the 'data' was left out of the netconf-config-change event.

1) Access control is effectively disabled by copying config nodes
into an 'anyxml' container within a notification.  Sensitive data
like passwords can be transferred to a client without read privilege
for that data.

2) NETCONF notifications may not be reliable.
Replay is optional to implement.  RFC 5277 is silent
about transport requirements for notification delivery.

For example if the receiver is blocked so that notifications
cannot be sent on a subscription session, a server with
finite resources will eventually be unable to store new
events.

There is one mention of resources in the RFC, wrt/ replay:

   The actual number of stored notifications available for retrieval at
   any given time is a NETCONF server implementation-specific matter.
   Control parameters for this aspect of the feature are outside the
   scope of this document.

Note that notifications can not be retrieved in NETCONF.
This text should say "available for delivery".

Notifications do not have sequence identifiers.
There is no way for a client to tell if a notification was dropped
by the server.

Andy

---

From: Mandy Liu <[email-masked]>
Date: Mon, 8 Jun 2015 01:21:09 +0000

Thanks for your important information, Andy!
+ Roy and Victor.

Hi Roy and Victor,

Andy shared some important information about " why the 'data' was left out of the netconf-config-change event" with us. FYI.

Regards,
Mandy

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 08, 2015 12:05 AM
To: Mandy Liu
Cc: Juergen Schoenwaelder; [email-masked]; Kai Lin; Robert Ottinger; [email-masked]; Athanasios Kyparlis
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

Hi,

There are (at least) 2 technical issues you should consider, in case you are wondering why the 'data' was left out of the netconf-config-change event.

1) Access control is effectively disabled by copying config nodes into an 'anyxml' container within a notification.  Sensitive data like passwords can be transferred to a client without read privilege for that data.

2) NETCONF notifications may not be reliable.
Replay is optional to implement.  RFC 5277 is silent about transport requirements for notification delivery.

For example if the receiver is blocked so that notifications cannot be sent on a subscription session, a server with finite resources will eventually be unable to store new events.

Notifications do not have sequence identifiers.
There is no way for a client to tell if a notification was dropped by the server.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 8 Jun 2015 18:29:09 +0000

Hi,

one follow-on question regarding item 2 that Andy mentions:  I am not sure what unreliable transport has to do with leaving out data from the config-change event?  Those seem to be separate, orthogonal issues.  (Obviously, if you want to rely on notifications to "stay on top" of configuration changes, you need a reliability mechanism. But this does not explain why you omit data from the payload.)  

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mandy Liu
Sent: Sunday, June 07, 2015 6:21 PM
To: Andy Bierman
Cc: Robert Ottinger; [email-masked]; Roy Finlay; Athanasios Kyparlis; Kai Lin; Victor Santos; [email-masked]
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

Hi Roy and Victor,

Regards,
Mandy

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]]
Sent: Monday, June 08, 2015 12:05 AM
To: Mandy Liu
Cc: Juergen Schoenwaelder; [email-masked]; Kai Lin; Robert Ottinger; [email-masked]; Athanasios Kyparlis
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information

Hi,

Andy

>> > Since you plan to augment a notification, this won't be config true data (this is what the statement in RFC 6020 really hints at). See also the definition of 'configuration data' in section 3 of…
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 12:06:35 -0700

> one follow-on question regarding item 2 that Andy mentions:  I am not sure what unreliable transport has to do with leaving out data from the config-change event?  Those seem to be separate, orthog…

Access control cannot be enforced.
The WG also wanted to minimize the size of the notification.

Using the netconf-config-change to replicate a datastore
would work OK if you add a sequence-id for netconf-config-change
events.  That way if your replication client detects a gap in
the sequencing, it can do a <get-config> to re-sync.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 22:06:58 +0200

> the sequencing, it can do a <get-config> to re-sync.

This reminds me after several years we still do not have a simple
version number or version hash for the configuration itself. We
should eventually fix this, no?

/js

PS: I have removed lots of email addresses, I assume people interested
    are on the list anyway. ;-)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 13:15:09 -0700

> should eventually fix this, no?

This was in NETCONF Efficiency Extensions.
We support the "config-id" capability in our server.
An ETag for the entire config is required for RESTCONF.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 22:19:58 +0200

> An ETag for the entire config is required for RESTCONF.

As I said, we talked about it several times - can we eventually make
it a standard (that works for NC, RC, and friends equally well)?

/js