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

[Andy Bierman <[e-mail]>]

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


On Tue, Jun 2, 2015 at 12:18 AM, Mandy Liu <[e-mail]> wrote:
> 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:[e-mail]]
> Sent: Tuesday, June 02, 2015 2:48 PM
> To: Mandy Liu
> Cc: [e-mail]; Kai Lin; Robert Ottinger; [e-mail]; 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
>
> On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote:
>> 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 {
>>          type instance-identifier;
>>         description
>>         .....
>>      }
>>      leaf operation {
>>          type nc:edit-operation-type;
>>         description
>>              .....
>>      }
>>      anyxml data;
>>  }
>>
>> Regards,
>> Mandy
>>
>> -----Original Message-----
>> From: Juergen Schoenwaelder
>> [mailto:[e-mail]]
>> Sent: Monday, June 01, 2015 5:55 PM
>> To: Mandy Liu
>> Cc: [e-mail]; Kai Lin; Robert Ottinger;
>> [e-mail]; 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:
>>
>>    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
>>
>> On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote:
>> > 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:[e-mail]]
>> > Sent: Monday, June 01, 2015 3:26 PM
>> > To: Mandy Liu
>> > Cc: [e-mail]; Kai Lin; Robert Ottinger;
>> > [e-mail]; 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:
>> >
>> > > [...] 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> > Fax:   [phone]         <http://www.jacobs-university.de/>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>