Re: [netmod] vs

[Robert Wilton]

On 28/09/2017 16:39, t.petch wrote:

Robert

I would like you to tweak the definition of running configuration
datastore slightly.

You say

" The running configuration datastore () is a configuration
   datastore that holds the complete current configuration
   on the device"

which I see as black and white, the terminology is .

But then you say

"This datastore is commonly referred to
   as "".

which I see as introducing wiggle room with the use of 'commonly' so I
would like you to excise 'commonly' leaving

NEW
This datastore is referred to as "".
Yes. fine with me.  We should also make the equivalent update for the 
other datastore definitions as well.


Thanks,
Rob



Black and white.

Tom Petch

- Original Message -
From: "Robert Wilton" 
Sent: Thursday, September 28, 2017 10:37 AM

After comment from the other authors, an updated proposed description
for  is as follows:

OLD:

4.3. The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device. It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage

to

   allow  to persist across reboots.

NEW:

4.1.3. The Running Configuration Datastore ()

   The running configuration datastore () is aconfiguration
   datastore that holds the complete current configuration
   on the device. It may include configuration that requires further
   transformation before it can be applied, e.g., inactive
   configuration, or template-mechanism-oriented configuration that
   needs further expansion. However,  MUST always be a 'valid
   configuration data tree' as defined in Section 8.1 of [RFC7950].

MUST be supported if the device can be configured via
   conventional configuration datastores.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage

to

   allow  to persist across reboots.


Given that the definition of  and  are being

updated,

I think that the definitions should similarly be updated. Hence I

propose:



OLD:
   o running configuration datastore: A configuration datastore holding
   the current configuration of the device. It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion. This datastore is commonly referred to
   as "".

NEW (based on the new description of running above):
   o running configuration datastore: A configuration datastore holding
   the current configuration of the device. It may include
   configuration that requires furthertransformations before it can
   be applied. This datastore is commonly referred to
   as "".



OLD:

   o intended configuration: Configuration that is intended to be used
   by the device. For example, intended configuration excludes any
   inactive configuration and it would include configuration produced
   through the expansion of templates.


NEW (based on the proposed updated description of intended):

   o intended configuration: Configuration that is intended to be used
   by the device. It represents the configuration after all
   configuration transformations to  have been performed and
   is the configuration that the system attempts to apply.



It may also be helpful if we define "configuration transformation", or
would that be better captured in the introduction text?

A possible definition could be along the lines of:

   configuration transformation: The addition, modification or removal

of

   configuration between the  and  datastores.
   Examples of configuration transformations include the removal of
   inactive configuration and the configuration produced through the
   expansion of templates.

If I don't hear anything back, I'll take that as a tacit approval of
these proposed changes.

Thanks,
Rob


On 22/09/2017 18:12, Robert Wilton wrote:

Hi Tom,


On 22/09/2017 17:34, t.petch wrote:

Robert

I wonder if this says the opposite of what is intended

-  holds the complete current configuration on the device.

I agree.


- This could include inactiveconfiguration

I agree.


-  must always be a 'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

I agree.


Ergo, inactiveconfiguration must form part of a valid configuration
tree.

Ergo, inactive configuration can form part of a valid configuration
tree.


I thought the idea was that inactiveconfiguration was logically

removed

before validation but this seems to state the opposite..

I don't think that this is necessarily true. One choice is inactive
configuration is removed before validation, but this isn't quite

what

I'm proposing. I'm proposing that the act of validation itself is
refined (via an tbd inactive configuration draft) such that it

ignores

configuration nodes marked as ina

Re: [netmod] vs

[t.petch]

Robert

I would like you to tweak the definition of running configuration
datastore slightly.

You say

" The running configuration datastore () is a configuration
  datastore that holds the complete current configuration
  on the device"

which I see as black and white, the terminology is .

But then you say

"This datastore is commonly referred to
  as "".

which I see as introducing wiggle room with the use of 'commonly' so I
would like you to excise 'commonly' leaving

NEW
This datastore is referred to as "".

Black and white.

Tom Petch

- Original Message -
From: "Robert Wilton" 
Sent: Thursday, September 28, 2017 10:37 AM
>
> After comment from the other authors, an updated proposed description
> for  is as follows:
>
> OLD:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> NEW:
>
> 4.1.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () is aconfiguration
>   datastore that holds the complete current configuration
>   on the device. It may include configuration that requires further
>   transformation before it can be applied, e.g., inactive
>   configuration, or template-mechanism-oriented configuration that
>   needs further expansion. However,  MUST always be a 'valid
>   configuration data tree' as defined in Section 8.1 of [RFC7950].
>
>MUST be supported if the device can be configured via
>   conventional configuration datastores.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
>
> Given that the definition of  and  are being
updated,
> I think that the definitions should similarly be updated. Hence I
propose:
>
>
>
> OLD:
>   o running configuration datastore: A configuration datastore holding
>   the current configuration of the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion. This datastore is commonly referred to
>   as "".
>
> NEW (based on the new description of running above):
>   o running configuration datastore: A configuration datastore holding
>   the current configuration of the device. It may include
>   configuration that requires furthertransformations before it can
>   be applied. This datastore is commonly referred to
>   as "".
>
>
>
> OLD:
>
>   o intended configuration: Configuration that is intended to be used
>   by the device. For example, intended configuration excludes any
>   inactive configuration and it would include configuration produced
>   through the expansion of templates.
>
>
> NEW (based on the proposed updated description of intended):
>
>   o intended configuration: Configuration that is intended to be used
>   by the device. It represents the configuration after all
>   configuration transformations to  have been performed and
>   is the configuration that the system attempts to apply.
>
>
>
> It may also be helpful if we define "configuration transformation", or
> would that be better captured in the introduction text?
>
> A possible definition could be along the lines of:
>
>   configuration transformation: The addition, modification or removal
of
>   configuration between the  and  datastores.
>   Examples of configuration transformations include the removal of
>   inactive configuration and the configuration produced through the
>   expansion of templates.
>
> If I don't hear anything back, I'll take that as a tacit approval of
> these proposed changes.
>
> Thanks,
> Rob
>
>
> On 22/09/2017 18:12, Robert Wilton wrote:
> > Hi Tom,
> >
> >
> > On 22/09/2017 17:34, t.petch wrote:
> >> Robert
> >>
> >> I wonder if this says the opposite of what is intended
> >>
> >> -  holds the complete current configuration on the device.
> > I agree.
> >
> >>
> >> - This could include inactiveconfiguration
> > I agree.
> >
> >>
> >> -  must always be a 'valid configuration data tree' as
> >> defined in Section 8.1 of [RFC7950].
> > I agree.
> >
> >>
> >> Ergo, inactiveconfiguration must form part of a valid configuration
> >> tree.
> >
> > Ergo, inactive configuration can form part of a valid configuration
> > tree.
> >
> >>
> >> I thought the idea was that inactiveconfiguration was logically
removed
> >> before validation but this seems to state the opposite..
> > I don't think that this is necessarily true. One choice is inactive
> > configuration is removed before validation, but this isn't quite
what
> > I'm proposing. I'm proposing that the act of validation itself is
> > refined (via an tbd inactive configurat

Re: [netmod] vs

[Robert Wilton]

Hi,

After comment from the other authors, an updated proposed description 
for  is as follows:


OLD:

4.3.  The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device.  It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage to
   allow  to persist across reboots.

NEW:

4.1.3.  The Running Configuration Datastore ()

   The running configuration datastore () is aconfiguration
   datastore that holds the complete current configuration
   on the device.  It may include configuration that requires further
   transformation before it can be applied, e.g., inactive
   configuration, or template-mechanism-oriented configuration that
   needs further expansion.  However,  MUST always be a 'valid
   configuration data tree' as defined in Section 8.1 of [RFC7950].

    MUST be supported if the device can be configured via
   conventional configuration datastores.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage to
   allow  to persist across reboots.


Given that the definition of  and  are being updated, 
I think that the definitions should similarly be updated.  Hence I propose:




OLD:
   o  running configuration datastore: A configuration datastore holding
  the current configuration of the device.  It may include inactive
  configuration or template-mechanism-oriented configuration that
  require further expansion.  This datastore is commonly referred to
  as "".

NEW (based on the new description of running above):
   o  running configuration datastore: A configuration datastore holding
  the current configuration of the device. It may include
  configuration that requires furthertransformations before it can
  be applied. This datastore is commonly referred to
  as "".



OLD:

  o  intended configuration: Configuration that is intended to be used
  by the device.  For example, intended configuration excludes any
  inactive configuration and it would include configuration produced
  through the expansion of templates.


NEW (based on the proposed updated description of intended):

  o  intended configuration: Configuration that is intended to be used
 by the device. It represents the configuration after all
 configuration transformations to  have been performed and
 is the configuration that the system attempts to apply.



It may also be helpful if we define "configuration transformation", or 
would that be better captured in the introduction text?


A possible definition could be along the lines of:

 configuration transformation: The addition, modification or removal of
 configuration between the  and  datastores.
 Examples of configuration transformations include the removal of
 inactive configuration and the configuration produced through the
 expansion of templates.

If I don't hear anything back, I'll take that as a tacit approval of 
these proposed changes.


Thanks,
Rob


On 22/09/2017 18:12, Robert Wilton wrote:

Hi Tom,


On 22/09/2017 17:34, t.petch wrote:

Robert

I wonder if this says the opposite of what is intended

-  holds the complete  current configuration on the device.

I agree.



- This could include inactiveconfiguration

I agree.



  -  must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

I agree.



Ergo, inactiveconfiguration must form part of a valid configuration
tree.


Ergo, inactive configuration can form part of a valid configuration
tree.



I thought the idea was that inactiveconfiguration was logically removed
before validation but this seems to state the opposite..
I don't think that this is necessarily true.  One choice is inactive 
configuration is removed before validation, but this isn't quite what 
I'm proposing.  I'm proposing that the act of validation itself is 
refined (via an tbd inactive configuration draft) such that it ignores 
configuration nodes marked as inactive.


Thanks,
Rob



Tom Petch

- Original Message -
From: "Robert Wilton" 
Sent: Friday, September 22, 2017 10:03 AM


Hi,

Regarding whether  is always valid, the proposed modification
to the draft is to add the following text to section 4.3 that

describes

:

OLD:

4.3. The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device. It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage

to

   allow  to persist across reboots.

NEW:

4.3. The Running Configuration 

Re: [netmod] vs

[Robert Wilton]

We want to close on some of the NMDA document comments.  I'll send a 
separate summary for all the issues later, possible tomorrow.


In the absence of seeing any comments to the contrary, and with the 
change supported by the other authors, I will apply the proposed update 
to the  description below.


This should resolve two issues:
https://github.com/netmod-wg/datastore-dt/issues/9
 - Title: "Make it clear that validation of intended includes default 
values"


https://github.com/netmod-wg/datastore-dt/issues/3
- Title: "Enhance description of intended datastore"

Thanks,
Rob




3) I think that it would be useful to further refine my previous 
proposed text for intended, particularly rewriting the text on 
validation.  This should hopefully also address Balazs' concern about 
default values be included in validation.




4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It is tightly coupled to .  When
   data is written to , the data that is to be validated is
   also conceptually written to . Validation is performed on
   the contents of .

   For simple implementations,  and  are identical.

    does not persist across reboots; its relationship with
    makes that unnecessary.

   Currently there are no standard mechanisms defined that affect
    so that it would have different contents than ,
   but this architecture allows for such mechanisms to be defined.

   One example of such a mechanism is support for marking nodes as
   inactive in .  Inactive nodes are not copied to ,
   and are thus not taken into account when validating the
   configuration.

   Another example is support for templates.  Templates are expanded
   when copied into , and the expanded result is validated.




4.1.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It represents the configuration after all
   configuration transformations to  are performed (e.g.
   template expansion, removal of inactive configuration), and is the
   configuration that the system attempts to apply.

    is tightly coupled to . Whenever data is written
   to , then  is also immediately updated by
   performing all necessary transformations to the contents of 
   and then  is validated.

    may also be updated independently of  (e.g., if
   one of the configuration transformations is changed), but 
   must always be a 'valid configuration data tree' as defined in
   Section 8.1 of [RFC7950].

   For simple implementations,  and  are identical.

   The contents of  is also related to the 'config true'
   subset of , and hence a client can determine to what
   extent the intended configuration is currently in use by checking
   whether the contents of  also appears in .

    does not persist across reboots; its relationship with
    makes that unnecessary.

   Currently there are no standard mechanisms defined that affect
    so that it would have different contents than ,
   but this architecture allows for such mechanisms to be defined.

   One example of such a mechanism is support for marking nodes as
   inactive in .  Inactive nodes are not copied to .
   A second example is support for templates, which can perform
   transformations on the configuration from  to the
   configuration written to .



Thanks,
Rob





/martin
.



.



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

Re: [netmod] vs

[Robert Wilton]

Hi Tom,


On 22/09/2017 17:34, t.petch wrote:

Robert

I wonder if this says the opposite of what is intended

-  holds the complete  current configuration on the device.

I agree.



- This could include inactiveconfiguration

I agree.



  -  must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

I agree.



Ergo, inactiveconfiguration must form part of a valid configuration
tree.


Ergo, inactive configuration can form part of a valid configuration
tree.



I thought the idea was that inactiveconfiguration was logically removed
before validation but this seems to state the opposite..
I don't think that this is necessarily true.  One choice is inactive 
configuration is removed before validation, but this isn't quite what 
I'm proposing.  I'm proposing that the act of validation itself is 
refined (via an tbd inactive configuration draft) such that it ignores 
configuration nodes marked as inactive.


Thanks,
Rob



Tom Petch

- Original Message -
From: "Robert Wilton" 
Sent: Friday, September 22, 2017 10:03 AM


Hi,

Regarding whether  is always valid, the proposed modification
to the draft is to add the following text to section 4.3 that

describes

:

OLD:

4.3. The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device. It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage

to

   allow  to persist across reboots.

NEW:

4.3. The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device. This could, for example,

include

   inactiveconfiguration or template-mechanism-oriented configuration
   thatrequires further expansion.However,  must always be a
   'valid configuration data tree' as defined in Section 8.1 of

[RFC7950].

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage

to

   allow  to persist across reboots.

END


Then the intention is that if inactive or a templating solution is
standardized then those drafts would update the validation rules in

RFC

7950 such that  is still valid. E.g. an inactive config draft
would probably indicate that validation excludes all configuration

nodes

that are marked as inactive.

Does anyone have any comments?

Do we also need to state that  must always be a 'valid
configuration data tree'?

Thanks,
Rob


On 19/09/2017 16:22, Robert Wilton wrote:


On 19/09/2017 10:55, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 18/09/2017 19:25, Andy Bierman wrote:

On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund


> wrote:

Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>> wrote:

On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:

No. I do not agree that the MUST in RFC 7950 can be

removed.

I do not agree the architecture should update YANG at all.

OK.

I am with Andy here.  has always had the

requirement to be

valid and we are not supposed to change that. Mechanisms for

inactive

configuration or templating must be designed to be backwards

compatible

I think.

Ok. If we keep the requirement that  in itself must be
valid, it just restricts the usefulness/expressiveness of
inactive and
template mechanisms, but it might be ok.

I think that even w/o this requirement, the observable
behavior for a
client can be backwards compatible. For example, suppose we
have an
inactive access control rule that refers to a non-existing
interface in
. If a client that doesn't know anything about
inactive asks
for the contents of , our implementation removes the
inactive
nodes from the reply to the client. Only a client that
opts-in to
inactive will receive a reply with things that looks invalid
if you
don't take the inactive annotation into account.



There are many ways that validation can fail because inactive

nodes

are present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is

supposed

to continue to work.

Yes.


Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled
nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or . These
responses
include enabled and disabled nodes, so validation does not apply
for 
4) new style  (i.e.  parameter used) can

alter

any type of data node

//I think that inactive should always be an optional extension.

Not

everything needs the additional complexity.

Hence rather than tying this function to specific NETCONF

operations,

I would suggest that there should be an extra parameter (like for
with-defaults) to allo

Re: [netmod] vs

[t.petch]

Robert

I wonder if this says the opposite of what is intended

-  holds the complete  current configuration on the device.

- This could include inactiveconfiguration

 -  must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

Ergo, inactiveconfiguration must form part of a valid configuration
tree.

I thought the idea was that inactiveconfiguration was logically removed
before validation but this seems to state the opposite..

Tom Petch

- Original Message -
From: "Robert Wilton" 
Sent: Friday, September 22, 2017 10:03 AM

> Hi,
>
> Regarding whether  is always valid, the proposed modification
> to the draft is to add the following text to section 4.3 that
describes
> :
>
> OLD:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> NEW:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. This could, for example,
include
>   inactiveconfiguration or template-mechanism-oriented configuration
>   thatrequires further expansion.However,  must always be a
>   'valid configuration data tree' as defined in Section 8.1 of
[RFC7950].
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> END
>
>
> Then the intention is that if inactive or a templating solution is
> standardized then those drafts would update the validation rules in
RFC
> 7950 such that  is still valid. E.g. an inactive config draft
> would probably indicate that validation excludes all configuration
nodes
> that are marked as inactive.
>
> Does anyone have any comments?
>
> Do we also need to state that  must always be a 'valid
> configuration data tree'?
>
> Thanks,
> Rob
>
>
> On 19/09/2017 16:22, Robert Wilton wrote:
> >
> >
> > On 19/09/2017 10:55, Martin Bjorklund wrote:
> >> Robert Wilton  wrote:
> >>>
> >>> On 18/09/2017 19:25, Andy Bierman wrote:
> 
>  On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
  > wrote:
> 
>  Juergen Schoenwaelder   > wrote:
>  > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>  > >
>  > > > No. I do not agree that the MUST in RFC 7950 can be
>  removed.
>  > > > I do not agree the architecture should update YANG at all.
>  > > OK.
>  >
>  > I am with Andy here.  has always had the
>  requirement to be
>  > valid and we are not supposed to change that. Mechanisms for
>  inactive
>  > configuration or templating must be designed to be backwards
>  compatible
>  > I think.
> 
>  Ok. If we keep the requirement that  in itself must be
>  valid, it just restricts the usefulness/expressiveness of
>  inactive and
>  template mechanisms, but it might be ok.
> 
>  I think that even w/o this requirement, the observable
>  behavior for a
>  client can be backwards compatible. For example, suppose we
>  have an
>  inactive access control rule that refers to a non-existing
>  interface in
>  . If a client that doesn't know anything about
>  inactive asks
>  for the contents of , our implementation removes the
>  inactive
>  nodes from the reply to the client. Only a client that
>  opts-in to
>  inactive will receive a reply with things that looks invalid
>  if you
>  don't take the inactive annotation into account.
> 
> 
> 
>  There are many ways that validation can fail because inactive
nodes
>  are present,
>  and considered part of the validation.
> 
>  e,g, min-elements, max-elements, mandatory, unique.
> 
>  I think we all agree that validation on the enabled nodes is
supposed
>  to continue to work.
> >> Yes.
> >>
>  Here is an attempt at a backwards-compatible solution:
> 
>  1) current  and  responses only include enabled
>  nodes.
>  2) old-style  operations do not alter inactive nodes
>  3) NMDA clients use , not  or . These
>  responses
>  include enabled and disabled nodes, so validation does not apply
>  for 
>  4) new style  (i.e.  parameter used) can
alter
>  any type of data node
> >>> //I think that inactive should always be an optional extension.
Not
> >>> everything needs the additional complexity.
> >>>
> >>> Hence rather than tying this function to specific NETCONF
operations,
> >>> I would suggest that there shoul

Re: [netmod] vs

[Robert Wilton]

Hi,

Regarding whether  is always valid, the proposed modification 
to the draft is to add the following text to section 4.3 that describes 
:


OLD:

4.3.  The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device.  It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage to
   allow  to persist across reboots.

NEW:

4.3.  The Running Configuration Datastore ()

   The running configuration datastore () holds the complete
   current configuration on the device.  This could, for example, include
   inactiveconfiguration or template-mechanism-oriented configuration
   thatrequires further expansion.However,  must always be a
   'valid configuration data tree' as defined in Section 8.1 of [RFC7950].

   If a device does not have a distinct  and non-volatile is
   available, the device will typically use that non-volatile storage to
   allow  to persist across reboots.

END


Then the intention is that if inactive or a templating solution is 
standardized then those drafts would update the validation rules in RFC 
7950 such that  is still valid.  E.g. an inactive config draft 
would probably indicate that validation excludes all configuration nodes 
that are marked as inactive.


Does anyone have any comments?

Do we also need to state that  must always be a 'valid 
configuration data tree'?


Thanks,
Rob


On 19/09/2017 16:22, Robert Wilton wrote:



On 19/09/2017 10:55, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 18/09/2017 19:25, Andy Bierman wrote:


On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund mailto:m...@tail-f.com>> wrote:

 Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>> wrote:
 > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
 > >
 > > > No.  I do not agree that the MUST in RFC 7950 can be 
removed.

 > > > I do not agree the architecture should update YANG at all.
 > > OK.
 >
 > I am with Andy here.  has always had the 
requirement to be

 > valid and we are not supposed to change that. Mechanisms for
 inactive
 > configuration or templating must be designed to be backwards
 compatible
 > I think.

 Ok.  If we keep the requirement that  in itself must be
 valid, it just restricts the usefulness/expressiveness of 
inactive and

 template mechanisms, but it might be ok.

 I think that even w/o this requirement, the observable 
behavior for a
 client can be backwards compatible.  For example, suppose we 
have an

 inactive access control rule that refers to a non-existing
 interface in
 .  If a client that doesn't know anything about 
inactive asks
 for the contents of , our implementation removes the 
inactive
 nodes from the reply to the client.  Only a client that 
opts-in to
 inactive will receive a reply with things that looks invalid 
if you

 don't take the inactive annotation into account.



There are many ways that validation can fail because inactive nodes
are present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed
to continue to work.

Yes.


Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled
nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These
responses
     include enabled and disabled nodes, so validation does not apply
for 
4) new style  (i.e.  parameter used) can alter
any type of data node

//I think that inactive should always be an optional extension.  Not
everything needs the additional complexity.

Hence rather than tying this function to specific NETCONF operations,
I would suggest that there should be an extra parameter (like for
with-defaults) to allow a client to indicate to the server that a get
or edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during
a get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during
an edit-data request then the request cannot include an extra inactive
meta-data.  The request is processed in a way that is equivalent to an
existing NETCONF implementation, but it may unknowingly remove some
inactive configuration (e.g. via a replace or remove operation on an
inactive node).  Operations like create, delete, none, replace should
all treat an inactive target node the same way as in the node doesn't
exist (e.g. delete on an inactive node would return a "da

Re: [netmod] vs

[Robert Wilton]

On 19/09/2017 10:55, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 18/09/2017 19:25, Andy Bierman wrote:


On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund mailto:m...@tail-f.com>> wrote:

 Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>> wrote:
 > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
 > >
 > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
 > > > I do not agree the architecture should update YANG at all.
 > > OK.
 >
 > I am with Andy here.  has always had the requirement to be
 > valid and we are not supposed to change that. Mechanisms for
 inactive
 > configuration or templating must be designed to be backwards
 compatible
 > I think.

 Ok.  If we keep the requirement that  in itself must be
 valid, it just restricts the usefulness/expressiveness of inactive and
 template mechanisms, but it might be ok.

 I think that even w/o this requirement, the observable behavior for a
 client can be backwards compatible.  For example, suppose we have an
 inactive access control rule that refers to a non-existing
 interface in
 .  If a client that doesn't know anything about inactive asks
 for the contents of , our implementation removes the inactive
 nodes from the reply to the client.  Only a client that opts-in to
 inactive will receive a reply with things that looks invalid if you
 don't take the inactive annotation into account.



There are many ways that validation can fail because inactive nodes
are present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed
to continue to work.

Yes.


Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled
nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These
responses
     include enabled and disabled nodes, so validation does not apply
for 
4) new style  (i.e.  parameter used) can alter
any type of data node

//I think that inactive should always be an optional extension.  Not
everything needs the additional complexity.

Hence rather than tying this function to specific NETCONF operations,
I would suggest that there should be an extra parameter (like for
with-defaults) to allow a client to indicate to the server that a get
or edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during
a get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during
an edit-data request then the request cannot include an extra inactive
meta-data.  The request is processed in a way that is equivalent to an
existing NETCONF implementation, but it may unknowingly remove some
inactive configuration (e.g. via a replace or remove operation on an
inactive node).  Operations like create, delete, none, replace should
all treat an inactive target node the same way as in the node doesn't
exist (e.g. delete on an inactive node would return a "data-missing"
error), this ensures that the behaviour that an unaware client
observes is the same as the existing behaviour that it would expect
from a regular 6241 compliant NETCONF implementation.
4) It a client makes a get request including the "with-inactive"
parameter then they also get the inactive nodes as well, marked with a
meta-data annotation.
5) If a client makes an edit request including the "with-inactive"
parameter, then the inactive meta-data annotation can be used to label
inactive nodes.  Inactive nodes are regarded as regular data nodes for
create/delete/replace/none operation error checking.

I think that this approach is similar (perhaps even the same) as
Martin described.

This is indeed how our implementation works (except I think we don't
do 5; if the client sends an "inactive" attribute it doesn't have to
also send with-inactive).


Note that the YANG MUST rule still applies, because validation is only
done on enabled nodes.
It is only the response message representations that cannot be
validated, not the contents
of  on a server.

So the question is how we can make sure that the text in the NMDA
draft covers this yet-to-be-defined feature w/o having to define it
now?  We thought that the current text was sufficient, but do we have
to make any changes to it?
1) Do we also need to illustrate a similar proof of concept templating 
implementation to show that templating could work whilst keeping running 
valid?  I would prefer that this is just deferred to whichever draft 
defines templating.


2) I think that we need to reach a decision as to whether the NMDA 
architecture needs to explicitly state that  is always

Re: [netmod] vs

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 18/09/2017 19:25, Andy Bierman wrote:
> >
> >
> > On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund  > > wrote:
> >
> > Juergen Schoenwaelder  > > wrote:
> > > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> > > >
> > > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > > > I do not agree the architecture should update YANG at all.
> > > > OK.
> > >
> > > I am with Andy here.  has always had the requirement to be
> > > valid and we are not supposed to change that. Mechanisms for
> > inactive
> > > configuration or templating must be designed to be backwards
> > compatible
> > > I think.
> >
> > Ok.  If we keep the requirement that  in itself must be
> > valid, it just restricts the usefulness/expressiveness of inactive and
> > template mechanisms, but it might be ok.
> >
> > I think that even w/o this requirement, the observable behavior for a
> > client can be backwards compatible.  For example, suppose we have an
> > inactive access control rule that refers to a non-existing
> > interface in
> > .  If a client that doesn't know anything about inactive asks
> > for the contents of , our implementation removes the inactive
> > nodes from the reply to the client.  Only a client that opts-in to
> > inactive will receive a reply with things that looks invalid if you
> > don't take the inactive annotation into account.
> >
> >
> >
> > There are many ways that validation can fail because inactive nodes
> > are present,
> > and considered part of the validation.
> >
> > e,g, min-elements, max-elements, mandatory, unique.
> >
> > I think we all agree that validation on the enabled nodes is supposed
> > to continue to work.

Yes.

> > Here is an attempt at a backwards-compatible solution:
> >
> > 1) current  and  responses only include enabled
> > nodes.
> > 2) old-style  operations do not alter inactive nodes
> > 3) NMDA clients use , not  or .  These
> > responses
> >     include enabled and disabled nodes, so validation does not apply
> > for 
> > 4) new style  (i.e.  parameter used) can alter
> > any type of data node
> //I think that inactive should always be an optional extension.  Not
> everything needs the additional complexity.
> 
> Hence rather than tying this function to specific NETCONF operations,
> I would suggest that there should be an extra parameter (like for
> with-defaults) to allow a client to indicate to the server that a get
> or edit request is using the "with-inactive" extension.
> 1) The server should also have a capability (or perhaps a leaf defined
> in YANG library) to indicate that it supports inactive configuration.
> 2) If a client doesn't use the extra "with-inactive" parameter during
> a get request then only active nodes are returned.
> 3) If a client doesn't use the extra "with-inactive" parameter during
> an edit-data request then the request cannot include an extra inactive
> meta-data.  The request is processed in a way that is equivalent to an
> existing NETCONF implementation, but it may unknowingly remove some
> inactive configuration (e.g. via a replace or remove operation on an
> inactive node).  Operations like create, delete, none, replace should
> all treat an inactive target node the same way as in the node doesn't
> exist (e.g. delete on an inactive node would return a "data-missing"
> error), this ensures that the behaviour that an unaware client
> observes is the same as the existing behaviour that it would expect
> from a regular 6241 compliant NETCONF implementation.
> 4) It a client makes a get request including the "with-inactive"
> parameter then they also get the inactive nodes as well, marked with a
> meta-data annotation.
> 5) If a client makes an edit request including the "with-inactive"
> parameter, then the inactive meta-data annotation can be used to label
> inactive nodes.  Inactive nodes are regarded as regular data nodes for
> create/delete/replace/none operation error checking.
> 
> I think that this approach is similar (perhaps even the same) as
> Martin described.

This is indeed how our implementation works (except I think we don't
do 5; if the client sends an "inactive" attribute it doesn't have to
also send with-inactive).

> > Note that the YANG MUST rule still applies, because validation is only
> > done on enabled nodes.
> > It is only the response message representations that cannot be
> > validated, not the contents
> > of  on a server.

So the question is how we can make sure that the text in the NMDA
draft covers this yet-to-be-defined feature w/o having to define it
now?  We thought that the current text was sufficient, but do we have
to make any changes to it?


/martin

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

Re: [netmod] vs

[Robert Wilton]

On 18/09/2017 19:25, Andy Bierman wrote:



On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund > wrote:


Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>> wrote:
> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >
> > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
>
> I am with Andy here.  has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for
inactive
> configuration or templating must be designed to be backwards
compatible
> I think.

Ok.  If we keep the requirement that  in itself must be
valid, it just restricts the usefulness/expressiveness of inactive and
template mechanisms, but it might be ok.

I think that even w/o this requirement, the observable behavior for a
client can be backwards compatible.  For example, suppose we have an
inactive access control rule that refers to a non-existing
interface in
.  If a client that doesn't know anything about inactive asks
for the contents of , our implementation removes the inactive
nodes from the reply to the client.  Only a client that opts-in to
inactive will receive a reply with things that looks invalid if you
don't take the inactive annotation into account.



There are many ways that validation can fail because inactive nodes 
are present,

and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed 
to continue to work.


Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These 
responses
    include enabled and disabled nodes, so validation does not apply 
for 
4) new style  (i.e.  parameter used) can alter 
any type of data node
//I think that inactive should always be an optional extension.  Not 
everything needs the additional complexity.


Hence rather than tying this function to specific NETCONF operations, I 
would suggest that there should be an extra parameter (like for 
with-defaults) to allow a client to indicate to the server that a get or 
edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined 
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during a 
get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during an 
edit-data request then the request cannot include an extra inactive 
meta-data.  The request is processed in a way that is equivalent to an 
existing NETCONF implementation, but it may unknowingly remove some 
inactive configuration (e.g. via a replace or remove operation on an 
inactive node).  Operations like create, delete, none, replace should 
all treat an inactive target node the same way as in the node doesn't 
exist (e.g. delete on an inactive node would return a "data-missing" 
error), this ensures that the behaviour that an unaware client observes 
is the same as the existing behaviour that it would expect from a 
regular 6241 compliant NETCONF implementation.
4) It a client makes a get request including the "with-inactive" 
parameter then they also get the inactive nodes as well, marked with a 
meta-data annotation.
5) If a client makes an edit request including the "with-inactive" 
parameter, then the inactive meta-data annotation can be used to label 
inactive nodes.  Inactive nodes are regarded as regular data nodes for 
create/delete/replace/none operation error checking.


I think that this approach is similar (perhaps even the same) as Martin 
described.


Thanks,
Rob




Note that the YANG MUST rule still applies, because validation is only 
done on enabled nodes.
It is only the response message representations that cannot be 
validated, not the contents

of  on a server.



/martin


Andy



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

Re: [netmod] vs

[Andy Bierman]

On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
> > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> > >
> > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > > I do not agree the architecture should update YANG at all.
> > > OK.
> >
> > I am with Andy here.  has always had the requirement to be
> > valid and we are not supposed to change that. Mechanisms for inactive
> > configuration or templating must be designed to be backwards compatible
> > I think.
>
> Ok.  If we keep the requirement that  in itself must be
> valid, it just restricts the usefulness/expressiveness of inactive and
> template mechanisms, but it might be ok.
>
> I think that even w/o this requirement, the observable behavior for a
> client can be backwards compatible.  For example, suppose we have an
> inactive access control rule that refers to a non-existing interface in
> .  If a client that doesn't know anything about inactive asks
> for the contents of , our implementation removes the inactive
> nodes from the reply to the client.  Only a client that opts-in to
> inactive will receive a reply with things that looks invalid if you
> don't take the inactive annotation into account.
>
>
>
There are many ways that validation can fail because inactive nodes are
present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed to
continue to work.

Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These responses
include enabled and disabled nodes, so validation does not apply for

4) new style  (i.e.  parameter used) can alter any
type of data node

Note that the YANG MUST rule still applies, because validation is only done
on enabled nodes.
It is only the response message representations that cannot be validated,
not the contents
of  on a server.



> /martin
>

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

Re: [netmod] vs

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> > 
> > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
> 
> I am with Andy here.  has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for inactive
> configuration or templating must be designed to be backwards compatible
> I think.

Ok.  If we keep the requirement that  in itself must be
valid, it just restricts the usefulness/expressiveness of inactive and
template mechanisms, but it might be ok.

I think that even w/o this requirement, the observable behavior for a
client can be backwards compatible.  For example, suppose we have an
inactive access control rule that refers to a non-existing interface in
.  If a client that doesn't know anything about inactive asks
for the contents of , our implementation removes the inactive
nodes from the reply to the client.  Only a client that opts-in to
inactive will receive a reply with things that looks invalid if you
don't take the inactive annotation into account.



/martin

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

Re: [netmod] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Andy Bierman]

On Mon, Sep 18, 2017 at 9:21 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >
> > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
>
> I am with Andy here.  has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for inactive
> configuration or templating must be designed to be backwards compatible
> I think.
>
>
I have been trying to think of a way that an enterprise-wide flag day
upgrade is not required,
but no luck so far. As Phil pointed out, if 1 client is using disabled
nodes,
unaware clients clients might end up deleting them if disabled nodes
are just omitted from  responses. (e.g., replace operation).

A client has no requirement to maintain attributes sent with server
responses
(unlike the server for  -> ), so returning the disabled
nodes
to an unaware client is no solution either.

It looks to me that an operator has to make sure all apps that alter
configuration
are aware of the disabled nodes.

IMO a standard attribute should be defined using RFC 7952:

  md:annotation enabled {
type boolean;
description "...";
  }

Even if the server supports vendor-specific attributes, it has to report
this attribute as well.
The default is enabled, so only disabled nodes need this attribute.
Standard configuration can wait.  Standard reporting should not wait.

Since clients can ignore YANG extensions, a new version of YANG will be
needed eventually,
but at least this allows 3rd party clients to recognize disabled nodes from
any vendor.



/js
>
>

Andy


> --
> 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] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Juergen Schoenwaelder]

On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> 
> > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > I do not agree the architecture should update YANG at all.
> OK.

I am with Andy here.  has always had the requirement to be
valid and we are not supposed to change that. Mechanisms for inactive
configuration or templating must be designed to be backwards compatible
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 

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

Re: [netmod] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Robert Wilton]

On 18/09/2017 17:03, Andy Bierman wrote:



On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton > wrote:




On 18/09/2017 15:21, Andy Bierman wrote:



On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton mailto:rwil...@cisco.com>> wrote:

Hi Andy,

At the moment, NMDA does not change the definition of
 for a standards compliant implementation of
YANG/NETCONF/RESTCONF.  It is still the same as in 7950, and
 must still be a "valid configuration data tree" for
a standards complaint implementation.

However, the draft acknowledges that proprietary extensions
exist that can modify the behaviour of  in ways that
means that  is not always a valid configuration data
tree.  The draft gives two examples of how  could be
manipulated (inactive config, and templates).


I don't see how NMDA can both acknowledge and violate the MUST be
valid in RFC 7950.
That statement is quite clear in RFC 7950.

I think that NMDA acknowledges non standard extensions could exist
that would violate RFC 7950 if/when those features are used, and
provides a standard architecture (i.e. the definition of
) to allow devices to expose the effects of those
bespoke features in a standard way.

Phil had proposed adding the following text on validation:

+The implication of the existence of templating mechanisms is that
+ is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may not be satisfied by  itself.

Do you think that text like this would help?  Or perhaps more
generically, something like this:



No.  I do not agree that the MUST in RFC 7950 can be removed.
I do not agree the architecture should update YANG at all.

OK.

So, can the NMDA draft just be silent about whether  is valid 
or not?  I.e. allowing the current statement in 7950 to stand.  That way 
if inactive or templating are standardized, and if the standard solution 
means that running is no longer always valid, then those drafts can 
update 7950 as appropriate.


The NMDA architecture can still specify  and also still 
specify that it is always valid, and explain its relationship to 
 and .


Thanks,
Rob




Andy

The implication of the existence of mechanisms that can allow
 to differ from  means that  is no
longer guaranteed to always be valid.  However, when any
change is made to ,  must also be updated at
the same time and be successfully validated before the operation
on  can be completed.

Obviously this would then need to update 7950.



If those extensions are standardized then I think it is
likely that those RFCs would need to update 7950 to indicate
that  isn't necessarily a "valid configuration data
tree" when those extensions are used.  But I don't think that
needs to be stated in the NMDA architecture at this time.


 Right -- because 7950 still holds any any server that does not
have a valid 
is non-compliant to 7950.

I agree.

Thanks,
Rob




Andy

So, what is ?
 - this is meant to represent the configuration that the
system will actually attempt to apply after any and all
manipulation (e.g. by templates, inactive removal, perhaps
system scripts, etc) of the configuration has been performed.
 - it must always be a valid configuration data tree.
 - If  is updated then  is always updated
at the same time.  Hence, any successful change to 
requires that  has also been updated and
validated.  E.g. in RESTCONF terms, I think that both
 and  should get the same last-change
timestamp whenever  is updated.
 - It provides a known fixed point so that any client can see
the full validated config, i.e. even for devices that
implement proprietary manipulations of the configuring in
.
 - If the device doesn't support any extra proprietary config
manipulations, then  is identical to .

I think that we can possibly do a bit more to better define
what .  My previous suggestion as an improvement
was below (perhaps you think it needs more clarification)?:

*OLD:*

4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a
read-only
   configuration datastore.  It is tightly coupled to
. When
   data is written to , the data that is to be
validated is
   also conceptually written to .  Validation is
performed on
   the contents of .

   For simple implementations,  and  are
identical.

    does not persist across reboots; its
relationship with
    makes that unnecessary.

   ...

*NEW:*

 

Re: [netmod] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Andy Bierman]

On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton  wrote:

>
>
> On 18/09/2017 15:21, Andy Bierman wrote:
>
>
>
> On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> At the moment, NMDA does not change the definition of  for a
>> standards compliant implementation of YANG/NETCONF/RESTCONF.  It is still
>> the same as in 7950, and  must still be a "valid configuration
>> data tree" for a standards complaint implementation.
>>
>> However, the draft acknowledges that proprietary extensions exist that
>> can modify the behaviour of  in ways that means that  is
>> not always a valid configuration data tree.  The draft gives two examples
>> of how  could be manipulated (inactive config, and templates).
>>
>
> I don't see how NMDA can both acknowledge and violate the MUST be valid in
> RFC 7950.
> That statement is quite clear in RFC 7950.
>
> I think that NMDA acknowledges non standard extensions could exist that
> would violate RFC 7950 if/when those features are used, and provides a
> standard architecture (i.e. the definition of ) to allow devices
> to expose the effects of those bespoke features in a standard way.
>
> Phil had proposed adding the following text on validation:
>
> +The implication of the existence of templating mechanisms is that
> + is now explicitly allowed to be invalid, since the
> +templating mechanism may be supplying additional data that satisfies
> +constraints that may not be satisfied by  itself.
>
> Do you think that text like this would help?  Or perhaps more generically,
> something like this:
>
>

No.  I do not agree that the MUST in RFC 7950 can be removed.
I do not agree the architecture should update YANG at all.

Andy


> The implication of the existence of mechanisms that can allow
>  to differ from  means that  is no
> longer guaranteed to always be valid.  However, when any
> change is made to ,  must also be updated at
> the same time and be successfully validated before the operation
> on  can be completed.
>
> Obviously this would then need to update 7950.
>
>
>
>
>> If those extensions are standardized then I think it is likely that those
>> RFCs would need to update 7950 to indicate that  isn't necessarily
>> a "valid configuration data tree" when those extensions are used.  But I
>> don't think that needs to be stated in the NMDA architecture at this time.
>>
>
>  Right -- because 7950 still holds any any server that does not have a
> valid 
> is non-compliant to 7950.
>
> I agree.
>
> Thanks,
> Rob
>
>
>
> Andy
>
>
>>
> So, what is ?
>>  - this is meant to represent the configuration that the system will
>> actually attempt to apply after any and all manipulation (e.g. by
>> templates, inactive removal, perhaps system scripts, etc) of the
>> configuration has been performed.
>>  - it must always be a valid configuration data tree.
>>  - If  is updated then  is always updated at the same
>> time.  Hence, any successful change to  requires that 
>> has also been updated and validated.  E.g. in RESTCONF terms, I think that
>> both  and   should get the same last-change timestamp
>> whenever  is updated.
>>  - It provides a known fixed point so that any client can see the full
>> validated config, i.e. even for devices that implement proprietary
>> manipulations of the configuring in .
>>  - If the device doesn't support any extra proprietary config
>> manipulations, then  is identical to .
>>
>> I think that we can possibly do a bit more to better define what
>> .  My previous suggestion as an improvement was below (perhaps
>> you think it needs more clarification)?:
>>
>> *OLD:*
>>
>> 4.4.  The Intended Configuration Datastore ()
>>
>>The intended configuration datastore () is a read-only
>>configuration datastore.  It is tightly coupled to .  When
>>data is written to , the data that is to be validated is
>>also conceptually written to .  Validation is performed on
>>the contents of .
>>
>>For simple implementations,  and  are identical.
>>
>> does not persist across reboots; its relationship with
>> makes that unnecessary.
>>
>>...
>>
>> *NEW:*
>>
>> 4.4.  The Intended Configuration Datastore ()
>>
>>The intended configuration datastore () is a read-only
>>configuration datastore.  It represents the configuration after all
>>configuration transformations to  are performed (e.g.
>>template expansion, inactive configuration removal), and is the
>>configuration that the system attempts to apply.
>>
>>It is tightly coupled to .  When data is written to
>>, the data that is to be validated is also conceptually
>>written to .  Validation is performed on the contents of
>>.
>>
>>For simple implementations,  and  are identical.
>>
>>The contents of  is also related to the 'config true'
>>subset of , and hence a client can determine to what
>>extent the intended configuration is currently applied by checking
>>whether the contents of  also appears in .
>>
>> d

Re: [netmod] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Robert Wilton]

On 18/09/2017 15:21, Andy Bierman wrote:



On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton > wrote:


Hi Andy,

At the moment, NMDA does not change the definition of 
for a standards compliant implementation of
YANG/NETCONF/RESTCONF.  It is still the same as in 7950, and
 must still be a "valid configuration data tree" for a
standards complaint implementation.

However, the draft acknowledges that proprietary extensions exist
that can modify the behaviour of  in ways that means that
 is not always a valid configuration data tree.  The
draft gives two examples of how  could be manipulated
(inactive config, and templates).


I don't see how NMDA can both acknowledge and violate the MUST be 
valid in RFC 7950.

That statement is quite clear in RFC 7950.
I think that NMDA acknowledges non standard extensions could exist that 
would violate RFC 7950 if/when those features are used, and provides a 
standard architecture (i.e. the definition of ) to allow 
devices to expose the effects of those bespoke features in a standard way.


Phil had proposed adding the following text on validation:

+The implication of the existence of templating mechanisms is that
+ is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may not be satisfied by  itself.

Do you think that text like this would help?  Or perhaps more 
generically, something like this:


The implication of the existence of mechanisms that can allow
 to differ from  means that  is no
longer guaranteed to always be valid.  However, when any
change is made to ,  must also be updated at
the same time and be successfully validated before the operation
on  can be completed.

Obviously this would then need to update 7950.



If those extensions are standardized then I think it is likely
that those RFCs would need to update 7950 to indicate that
 isn't necessarily a "valid configuration data tree" when
those extensions are used.  But I don't think that needs to be
stated in the NMDA architecture at this time.


 Right -- because 7950 still holds any any server that does not have a 
valid 

is non-compliant to 7950.

I agree.

Thanks,
Rob




Andy

So, what is ?
 - this is meant to represent the configuration that the system
will actually attempt to apply after any and all manipulation
(e.g. by templates, inactive removal, perhaps system scripts, etc)
of the configuration has been performed.
 - it must always be a valid configuration data tree.
 - If  is updated then  is always updated at
the same time.  Hence, any successful change to  requires
that  has also been updated and validated. E.g. in
RESTCONF terms, I think that both  and   should
get the same last-change timestamp whenever  is updated.
 - It provides a known fixed point so that any client can see the
full validated config, i.e. even for devices that implement
proprietary manipulations of the configuring in .
 - If the device doesn't support any extra proprietary config
manipulations, then  is identical to .

I think that we can possibly do a bit more to better define what
.  My previous suggestion as an improvement was below
(perhaps you think it needs more clarification)?:

*OLD:*

4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It is tightly coupled to .  When
   data is written to , the data that is to be validated is
   also conceptually written to .  Validation is
performed on
   the contents of .

   For simple implementations,  and  are identical.

    does not persist across reboots; its relationship with
    makes that unnecessary.

   ...

*NEW:*

4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It represents the configuration after all
   configuration transformations to  are performed (e.g.
   template expansion, inactive configuration removal), and is the
   configuration that the system attempts to apply.

   It is tightly coupled to . When data is written to
   , the data that is to be validated is also conceptually
   written to .  Validation is performed on the contents of
   .

   For simple implementations,  and  are identical.

   The contents of  is also related to the 'config true'
   subset of , and hence a client can determine to what
   extent the intended configuration is currently applied by checking
   whether the contents of  also appears in .

    does not persist across reboots; its relationship with
    makes that unnecessary.

   ...

Thanks,
Rob


On 17/09/2017 16:31, Andy Bierman wrote:

Hi,

My concern is that t

Re: [netmod] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Andy Bierman]

On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton  wrote:

> Hi Andy,
>
> At the moment, NMDA does not change the definition of  for a
> standards compliant implementation of YANG/NETCONF/RESTCONF.  It is still
> the same as in 7950, and  must still be a "valid configuration
> data tree" for a standards complaint implementation.
>
> However, the draft acknowledges that proprietary extensions exist that can
> modify the behaviour of  in ways that means that  is not
> always a valid configuration data tree.  The draft gives two examples of
> how  could be manipulated (inactive config, and templates).
>

I don't see how NMDA can both acknowledge and violate the MUST be valid in
RFC 7950.
That statement is quite clear in RFC 7950.



> If those extensions are standardized then I think it is likely that those
> RFCs would need to update 7950 to indicate that  isn't necessarily
> a "valid configuration data tree" when those extensions are used.  But I
> don't think that needs to be stated in the NMDA architecture at this time.
>

 Right -- because 7950 still holds any any server that does not have a
valid 
is non-compliant to 7950.


Andy


>
So, what is ?
>  - this is meant to represent the configuration that the system will
> actually attempt to apply after any and all manipulation (e.g. by
> templates, inactive removal, perhaps system scripts, etc) of the
> configuration has been performed.
>  - it must always be a valid configuration data tree.
>  - If  is updated then  is always updated at the same
> time.  Hence, any successful change to  requires that 
> has also been updated and validated.  E.g. in RESTCONF terms, I think that
> both  and   should get the same last-change timestamp
> whenever  is updated.
>  - It provides a known fixed point so that any client can see the full
> validated config, i.e. even for devices that implement proprietary
> manipulations of the configuring in .
>  - If the device doesn't support any extra proprietary config
> manipulations, then  is identical to .
>
> I think that we can possibly do a bit more to better define what  is>.  My previous suggestion as an improvement was below (perhaps you think
> it needs more clarification)?:
>
> *OLD:*
>
> 4.4.  The Intended Configuration Datastore ()
>
>The intended configuration datastore () is a read-only
>configuration datastore.  It is tightly coupled to .  When
>data is written to , the data that is to be validated is
>also conceptually written to .  Validation is performed on
>the contents of .
>
>For simple implementations,  and  are identical.
>
> does not persist across reboots; its relationship with
> makes that unnecessary.
>
>...
>
> *NEW:*
>
> 4.4.  The Intended Configuration Datastore ()
>
>The intended configuration datastore () is a read-only
>configuration datastore.  It represents the configuration after all
>configuration transformations to  are performed (e.g.
>template expansion, inactive configuration removal), and is the
>configuration that the system attempts to apply.
>
>It is tightly coupled to .  When data is written to
>, the data that is to be validated is also conceptually
>written to .  Validation is performed on the contents of
>.
>
>For simple implementations,  and  are identical.
>
>The contents of  is also related to the 'config true'
>subset of , and hence a client can determine to what
>extent the intended configuration is currently applied by checking
>whether the contents of  also appears in .
>
> does not persist across reboots; its relationship with
> makes that unnecessary.
>...
>
> Thanks,
> Rob
>
> On 17/09/2017 16:31, Andy Bierman wrote:
>
> Hi,
>
> My concern is that the definition of  is being changed to
> include undefined and undeclared proprietary extensions.
> This is counter-productive to the IETF's stated goal of interoperability.
>
>
> Andy
>
>
> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund  wrote:
>
>> Andy Bierman  wrote:
>> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>> > j.schoenwael...@jacobs-university.de> wrote:
>> >
>> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>> > > > Hi,
>> > > >
>> > > > I strongly agree with Tom that the current draft is an update to RFC
>> > > 7950.
>> > > > I also strongly disagree with the decision to omit RFC 2119 in a
>> > > standards
>> > > > track document. IMO RFC 2119 terms need to be used in normative
>> text,
>> > > > especially when dealing with XPath and YANG compiler behavior.
>> > > >
>> > >
>> > > RFC 8174:
>> > >
>> > >o  These words can be used as defined here, but using them is not
>> > >   required.  Specifically, normative text does not require the use
>> > >   of these key words.  They are used for clarity and consistency
>> > >   when that is what's wanted, but a lot of normative text does not
>> > >   use them and is still normative.
>> > >
>> > >
>> > So what?
>> 

[netmod] vs [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

[Robert Wilton]

Hi Andy,

At the moment, NMDA does not change the definition of  for a 
standards compliant implementation of YANG/NETCONF/RESTCONF.  It is 
still the same as in 7950, and  must still be a "valid 
configuration data tree" for a standards complaint implementation.


However, the draft acknowledges that proprietary extensions exist that 
can modify the behaviour of  in ways that means that  
is not always a valid configuration data tree.  The draft gives two 
examples of how  could be manipulated (inactive config, and 
templates).


If those extensions are standardized then I think it is likely that 
those RFCs would need to update 7950 to indicate that  isn't 
necessarily a "valid configuration data tree" when those extensions are 
used.  But I don't think that needs to be stated in the NMDA 
architecture at this time.


So, what is ?
 - this is meant to represent the configuration that the system will 
actually attempt to apply after any and all manipulation (e.g. by 
templates, inactive removal, perhaps system scripts, etc) of the 
configuration has been performed.

 - it must always be a valid configuration data tree.
 - If  is updated then  is always updated at the 
same time.  Hence, any successful change to  requires that 
 has also been updated and validated.  E.g. in RESTCONF terms, 
I think that both  and   should get the same 
last-change timestamp whenever  is updated.
 - It provides a known fixed point so that any client can see the full 
validated config, i.e. even for devices that implement proprietary 
manipulations of the configuring in .
 - If the device doesn't support any extra proprietary config 
manipulations, then  is identical to .


I think that we can possibly do a bit more to better define what 
.  My previous suggestion as an improvement was below 
(perhaps you think it needs more clarification)?:


*OLD:*

4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It is tightly coupled to .  When
   data is written to , the data that is to be validated is
   also conceptually written to . Validation is performed on
   the contents of .

   For simple implementations,  and  are identical.

    does not persist across reboots; its relationship with
    makes that unnecessary.

   ...

*NEW:*

4.4.  The Intended Configuration Datastore ()

   The intended configuration datastore () is a read-only
   configuration datastore.  It represents the configuration after all
   configuration transformations to  are performed (e.g.
   template expansion, inactive configuration removal), and is the
   configuration that the system attempts to apply.

   It is tightly coupled to .  When data is written to
   , the data that is to be validated is also conceptually
   written to .  Validation is performed on the contents of
   .

   For simple implementations,  and  are identical.

   The contents of  is also related to the 'config true'
   subset of , and hence a client can determine to what
   extent the intended configuration is currently applied by checking
   whether the contents of  also appears in .

    does not persist across reboots; its relationship with
    makes that unnecessary.

   ...

Thanks,
Rob


On 17/09/2017 16:31, Andy Bierman wrote:

Hi,

My concern is that the definition of  is being changed to
include undefined and undeclared proprietary extensions.
This is counter-productive to the IETF's stated goal of interoperability.


Andy


On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund > wrote:


Andy Bierman mailto:a...@yumaworks.com>> wrote:
> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de
> wrote:
>
> > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > I strongly agree with Tom that the current draft is an
update to RFC
> > 7950.
> > > I also strongly disagree with the decision to omit RFC 2119 in a
> > standards
> > > track document. IMO RFC 2119 terms need to be used in
normative text,
> > > especially when dealing with XPath and YANG compiler behavior.
> > >
> >
> > RFC 8174:
> >
> >    o  These words can be used as defined here, but using them
is not
> >       required.  Specifically, normative text does not require
the use
> >       of these key words.  They are used for clarity and
consistency
> >       when that is what's wanted, but a lot of normative text
does not
> >       use them and is still normative.
> >
> >
> So what?
> Existing YANG specifications use RFC 2119 terms.
> This draft uses those terms, just with lower-case.

Actually, section 5.1 XPath Context in the revised datastore draft
uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
fact, the text in the draft is co