Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-01.txt

From: [email-masked]
Date: Mon, 13 Jul 2009 12:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : NETCONF Configuration Protocol
	Author(s)       : R. Enns, et al.
	Filename        : draft-ietf-netconf-4741bis-01.txt
	Pages           : 113
	Date            : 2009-07-13

The Network Configuration Protocol (NETCONF) defined in this document
provides mechanisms to install, manipulate, and delete the
configuration of network devices.  It uses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well
as the protocol messages.  The NETCONF protocol operations are
realized on top of a simple Remote Procedure Call (RPC) layer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 20 Jul 2009 17:15:36 +0200

Hello,
Where is the list of outstanding issue stored? It would be nice to have a list on a tracker or 
in the document itself. Keeping it only in private lists leads to the same comments popping up 
again and again. It also makes tracking issue for non-authors more difficult.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 21 Jul 2009 11:14:39 +0200

Hello,
Some comments:

- The role of warnings is still unclear.

- What does stop-on-error and continue-on-error mean if running is always valid?

- page 94) if a system does not support filtering of startup it could still support get-config 
without filters. So the description
"This is optional-to-implement on the agent because not all
agents will support filtering for this database."
Should be changed to
"Even if an agent supports the startup feature it MAY ignore filters for the startup datastore."

- the test option <test/>  should not be allowed for the running configuration, as it always 
has to be valid. See also discussion about the default value of the test option

- what happens if we delete the startup configuration and then the device boots. Describe!

- The candidate datastore is missing for delete-config in the YAM.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 21 Jul 2009 18:54:10 +0200

Hello,
Normative references to YANG and yang-types are missing.

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Jul 2009 23:59:19 +0200 (CEST)

> - The role of warnings is still unclear.

Yes, still an open issue.  Maybe we should disuss it in Stockholm.

> - What does stop-on-error and continue-on-error mean if running is always
> - valid?

stop-on-error means that as soon as a node is modified which would
result in an invalid config, the node and the rest of the edit-config
is ignored.  I don't really like this idea, since you get "some" valid
result, but you don't know what it is.

continue-on-error means that the node which would result in an invalid
config is skipped, and the rest of the edit-config is applied.

> - page 94) if a system does not support filtering of startup it could still
> - support get-config without filters. So the description

In an earlier msg Phil argued that get-config on startup shouldn't be
supported at all.

> - the test option <test/> should not be allowed for the running configuration,
> - as it always has to be valid. See also discussion about the default value of
> - the test option

Do you mean 'set'?

> - what happens if we delete the startup configuration and then the device
> - boots. Describe!

The text says:  

  Resets the device to its factory defaults

Do we need more text?

> - The candidate datastore is missing for delete-config in the YAM.

It is consistent with the text.  Should it be allowed?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 Jul 2009 00:10:46 +0200 (CEST)

> Normative references to YANG and yang-types are missing.

Thanks, I will add them.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 22 Jul 2009 14:33:49 +0200

Hello,

> config is skipped, and the rest of the edit-config is applied.

BALAZS: I understand the basic concept, but skipping one-or-more nodes might make some already 
configured nodes invalid as well, so it is a hell of a task to check. E.g.

there is a "must a == b;" statement on a
step 1) You set a to 100 : it is OK
step 2) You set a dozen other leafs somewhere in the model
step 3) You set b to 100 (whose previous value was 80): this fails because e.g., b has some 
strict restriction on it, or b depends on some external resource.

Lets assume b was the last thing to modify, so stop-on-error and continue-on-error mean the 
same thing in this case.

Unless you roll back step 1 you have got an invalid datastore. But first you have to find step 
1, then check any other changes that depend on step 1.

Also rolling back step 2 is NOT mentioned in NETCONF.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 22 Jul 2009 14:54:41 +0200

> In an earlier msg Phil argued that get-config on startup shouldn't be

BALAZS: That could be done, but my guess(!) is, that to return the complete startup inline 
should not be so difficult. Anyway the current sentence is wrong. If the filters are the 
problem, it should be the filters that are made optional.

>> - as it always has to be valid. See also discussion about the default value of

BALAZS: yes, sorry.

>   Resets the device to its factory defaults

BALAZS: You are right. This is mentioned in chapter 8.7.5.1. but not in 7.4.
Delete-config is a nice operation, it means different things for every datastore
- running: not allowed (could have been reset to factory default)
- startup: reset to factory default which is not the same as delete - they might return 
different things for a subsequent get-config
- candidate: make the datastore completely empty (or maybe not allowed?)

> It is consistent with the text.  Should it be allowed?

BALAZS: In the XSD it was allowed. I think we do need to state explicitly in the text whether 
delete-config on candidate is allowed or not.

It would be strange to have a delete-config operation that only works on the startup config, 
and there it does not delete a config, but rather resets it.
(I also don't understand why we want to allow delete on URL. This is not a file-manager, but 
forget this for now.)

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jul 2009 08:25:54 -0700

> Martin Bjorklund wrote:
....
> BALAZS: In the XSD it was allowed. I think we do need to state
> explicitly in the text whether delete-config on candidate is allowed or
> not.

I do not allow it.
The <candidate> is an internal data structure.
What does it mean to delete the candidate?
Isn't that just <discard-changes>, so there is no point in
using <delete-config>?

> 
> It would be strange to have a delete-config operation that only works on
> the startup config, and there it does not delete a config, but rather
> resets it.

no -- it deletes it.
a 'reset' would be like a 'restore' operation?

> (I also don't understand why we want to allow delete on URL. This is not
> a file-manager, but forget this for now.)

It is a file manager, when <url> is used.
If you allow the user to build up a bunch of
local files with copy-config to a URL, then allowing
the user to delete them makes sense.  There is no way
to list which files exist, which is a big hole, but...

Back to an issue to resolve on <startup>:

What if I can support a <get-config> on <startup> without any filters,
but that's all?  Can I reject any request with a filter as
an 'operation-failed' error? (IMO, yes)

I agree with Phil that there was never any intent to require
anything but a  manual 'save' operation.  The rest was supposed to be
optional to implement.

> Balazs

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 22 Jul 2009 18:48:08 +0200

> anything but a  manual 'save' operation.  The rest was supposed to be
Options
1) Just ignore the filters as if they were absent
2) Reject the get-config with filters
3) State that it is not supported for startup.

I see here a use case: I want to know what is the delta between startup and running.

Anyway we must choose between the 3 options and document it properly.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 22 Jul 2009 18:52:18 +0200

> a 'reset' would be like a 'restore' operation?
The draft says:
"Resets the device to its factory defaults" (chapter 8.7.5.1)

I thought delete a datastore means to delete all it's content, so if you call get-config 
subsequently it will return an empty <data/> reply.

It seems we better define delete-config more precisely. Please Martin add it to the open issues.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jul 2009 10:11:01 -0700

Balazs Lengyel wrote:
> I thought delete a datastore means to delete all it's content, so if you
> call get-config subsequently it will return an empty <data/> reply.
> 

I see what you mean.
I think Martin already provided the answer,
which is that the <running> config will be re-populated with
the factory defaults (according to possibly new boot-time config).
The <startup> is gone until it some session does a copy-config
from <running> to <startup> again.

What if the startup file is configurable on the agent?
So <delete-config> deletes the current startup file,
but if the agent reboots and the operator selects a different
stored startup file, then the <startup> config will reappear.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 22 Jul 2009 13:44:26 -0400

>the factory defaults (according to possibly new boot-time config).

Is this really what we want?  Shouldn't delete delete it
and a "restore-factory-defaults" operations restore the
factory defaults?

We don't need no stinking magic.

Note that delete deletes the contents of the database, not
the database itself.  So you don't lose your candidate
database, but it should be empty after a delete.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jul 2009 11:25:50 -0700

> We don't need no stinking magic.

I meant to say restored on the next reboot.
Not right away.  Good point.
The agent will auto-populate whatever it deems appropriate.
An empty config and a partial config are no different here.

I agree with you that calling this reset to
factory defaults is misleading.

> database, but it should be empty after a delete.

How is this different than <discard-changes>?
If 'none', then why bother?
But I don't really care, as long as the spec is clear
and everybody has to support the same thing.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 22 Jul 2009 14:19:14 -0400

>How is this different than <discard-changes>?

Discard changes reverts to the last committed version of the
configuration (equivalent to loading the committed config into
the candidate config database).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jul 2009 12:36:33 -0700

> the candidate config database).

Let me ask another way.

If I do a <get-config> on the <candidate> right afterwards,
what is returned?

discard-changes:

   <data>
     // all config=true nodes currently in <running>
   </data>

delete-config:

   <data/>

   OR

   <data>
     // all config=true nodes currently in <running>
   </data>

  OR

  something else?  if so, where do these contents
  magically appear from?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 Jul 2009 23:59:41 +0200 (CEST)

> database, but it should be empty after a delete.

RFC 4741 says:

  Delete a configuration datastore.

And if the target is a local file, shouldn't the file be removed (not
truncated to size 0)?

Further, the candidate cannot be deleted according to 4741
(delete-config is not listed in 8.3.5).

/martin

---

From: WashamFan <[email-masked]>
Date: Thu, 23 Jul 2009 10:06:52 +0800

Hi,

After reading all relevant comments, it seems to me that there
exists different semantics of <delete-config> to different <target>

I think, we should definitely spell out which datastores <delete-config> 
should apply to. When <delete-config> applies to a <target>, what
does it imply? reset/sync? empty the content? Or remove the datastore?
(And what should be done if expected datastore is lacking?)

washam

----- Original Message -----
From: Martin Bjorklund <[email-masked]>
Date: Thursday, July 23, 2009 6:02 am
Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt
To: [email-masked]
Cc: [email-masked]

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

---

From: Phil Shafer <[email-masked]>
Date: Thu, 23 Jul 2009 00:33:19 -0400

>  Delete a configuration datastore.

This makes little sense.  What does it mean to delete <running>?

>(delete-config is not listed in 8.3.5).

So should all this be called out explicitly in -bis?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 23 Jul 2009 00:29:37 -0400

>     // all config=true nodes currently in <running>

There are no config=false nodes in running.

>   <data/>

Yes, it should be empty.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Jul 2009 04:43:57 -0700

> There are no config=false nodes in running.

I see your point.
A delete-config could be seen as a shortcut way
to do an edit-config (operation=delete) on every
single top-level node in the candidate.

All implementations certainly allow that, or they are supposed to.
(Not sure if deleting a node that the agent insists on creating
again right away fits into this picture, though).

Is this something that comes up often?
No, but delete-config is rarely used anyway,
because it is such an extreme action.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Jul 2009 21:50:05 +0200 (CEST)

> This makes little sense.  What does it mean to delete <running>?

According to 4741, running cannot be deleted.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 08:59:38 -0700

> According to 4741, running cannot be deleted.

good!

I find the <copy-config> and <delete-config> operations
to be the absolute worst part of NETCONF.

It is obvious from studying the protocol that there was no
clear or shared understanding of the database architecture.
Now with partial-locking, it is even worse.

   * every agent MUST have a <running> database
   * every agent MUST have exactly 1 database that can
     be the target of an <edit-config> operation.
     (Writing to both <candidate> and <running> does not work!)
      * therefore the agent MUST support the :candidate OR
        :writable-running capabilities, but not both)
   * the :candidate and :startup capabilities are independent,
     not mutually exclusive.

(Is there any agreement on these points?)

I changed my mind on 'minimal <startup> operations'.
I think <get-config> and <validate> on the "NV version"
are too useful for operators to leave as optional.
So the table in 4741bis, 8.7.5.1 is OK

I do not like all the combinations for <copy-config>
that occur when :candidate and :startup are both supported.
Or for that matter, just :candidate.

8.3.5.1.  <get-config>, <edit-config>, <copy-config>, and <validate>

   The candidate configuration can be used as a source or target of any
   <get-config>, <edit-config>, <copy-config>, or <validate> operation
   as a <source> or <target> parameter.  The <candidate> element is used
   to indicate the candidate configuration:

This first sentence is clearly wrong.
You cannot copy from candidate to running.
You can only use <commit> for that.
(Not sure about copy from candidate to startup.)
You should not be able to copy from running to candidate either.
We have <discard-changes> for that.

I wish we had time to work on the NETCONF database architecture,
because it isn't very good.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 25 Jul 2009 12:15:29 -0400

>        :writable-running capabilities, but not both)

I think Martin's code suport this (both).

>We have <discard-changes> for that.

Are you really wanting CLRs for these?  I guess it's not "L" either,
since you'd need a matrix.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 10:01:24 -0700

> since you'd need a matrix.

You need a matrix and a week to figure it all out.

I actually want there to be just one simple way to
do what needs to be done on every agent.
I want the standard to clearly specify what every
agent MUST, SHOULD, or MAY do, for each of the
'one simple ways' of doing each task.

It is not clear if an agent will do the exact same thing every time
for each of these duplicate operations.  It only confuses people
who might be trying to learn NETCONF:  e.g.,
  * when should I use <commit> and when should I use <copy-config>?
  * I thought <discard-changes> was used to reset the candidate?
  * There is no test that says how <copy-config> interacts with
    locking and :confirmed-commit, so how does that work?
  * Can I <copy-config> inline config right into the <running>
    or <candidate>? Really? Then when do I use <edit-config>
    What is the difference?
  * What about this nc:operation thing?
    What if they are present in a <copy-config> operation?
    Does they get ignored or cause an error or what?

What you see as 'convenient', I see an reduced interoperability
and higher cost of training and adoption.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 25 Jul 2009 21:53:34 +0200 (CEST)

> > I think Martin's code suport this (both).

Yes it does.  I agree that other combinations are more useful, but
also this combination works.

> >> You can only use <commit> for that.

If you can copy from candidate to url X, and from url X to running,
why not copy from candidate to running directly?  (and IMO it means
just that).  It only works if you have a candidate AND
:writable-running of course.

> >> (Not sure about copy from candidate to startup.)

Same reasoning as above, but it depends how primitive we want the
startup to (minimally) be.

> >> We have <discard-changes> for that.

In my code I have a special case for copy from running to candidate -
it invokes the internal discard_changes() function.  It is a bit
unclear why we have two ways of doing this, but if we just wanted one
way, I'd remove discard-changes.

>     locking and :confirmed-commit, so how does that work?

The text says that when a lock is set, other sessions cannot modify
the locked db.  So if another session tries to copy-config, it will
fail.  Do we need more text?

If you're doing a confirmed commit w/o a lock, and the box supports
:writable-running, well, then you really should have taken a lock ;)
copy-config works just like edit-config in this case.

>     or <candidate>? Really? Then when do I use <edit-config>

Sure.

>     What is the difference?

copy-config replaces the *entire* datastore.  edit-config can replace
only the pieces you have in the PDU.  So use copy-config to save /
restore backups.

>     Does they get ignored or cause an error or what?

They will be treated as any other unknown attribute present in the
data.  I.e. generate an error.  Do we have to specify that unknown
elements and unknown attributes in the data are errors?  If so, does
it belong in yang or 4741bis?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 25 Jul 2009 22:05:27 +0200 (CEST)

> So the table in 4741bis, 8.7.5.1 is OK

What about filtering on the startup, do you think that should be
optional or not?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 15:56:50 -0700

> also this combination works.

I think the standard is poorly specified in this entire area.

So let's say User A locks the candidate and starts adding edits.
Then user B adds a new leaf direct to running.
How do you update the leaf in the candidate without
violating the lock?

And if candidate is not updated in this case, then
aren't you 'lying' to user A when you say a <validate>
on the candidate is OK?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 17:18:03 -0700

Martin Bjorklund wrote:
...
> way, I'd remove discard-changes.

At the time 4741 was written, the proponents of the candidate config
insisted we needed separate commands like <commit>
and <discard-changes> because they were so different from
the running config.  "A commit can fail, but a copy-config cannot",
was the logic I think.

If the database architecture was clear,
there would not be so many interpretations
of it that contradict this much.

We should deprecate <discard-changes> and <commit>,
and just use <copy-config> and <delete-config> for all databases.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 17:24:00 -0700

> What about filtering on the startup, do you think that should be

no -- full filtering must be supported.

this protocol already has more optional bells, whistles and flags
than a battleship.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 18:41:25 -0700

....
> and just use <copy-config> and <delete-config> for all databases.

but then again, <copy-config> allows the
<with-defaults> leaf to be used, so the matrix
is 3d, not 2d (source, target, with-defaults).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 26 Jul 2009 12:15:37 +0200 (CEST)

> and just use <copy-config> and <delete-config> for all databases.

<commit> has more parameters than <copy-config>, so I think it must
be kept.  Also, you cannot copy-config to running unless
:writable-running is advertised, so <commit> is needed.

/martin

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Sun, 26 Jul 2009 15:00:35 +0200

> because it isn't very good.

I wonder if others (many) feel the same?
Because if we do believe that the db architecture is not good enough, 
then we better
think about a possible better architecture now.... before we start 
adding all sorts
of new/other things.

apeaking as a contributer
Bert

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Jul 2009 08:21:17 -0700

> :writable-running is advertised, so <commit> is needed.

So is a copy-config from candidate to running
the same as a commit?  What if user A starts
a confirmed commit, then issues a copy-config
as the 2nd commit?  What happens?  When is copy-config
from candidate to running supposed to be used?

If copy-config from running to candidate is used instead
of discard-changes, then what happens if <with-defaults>
is set to 'explicit'?  How is the candidate config
supposed to function without any agent-created nodes in it?
What does it even mean to trim the defaults from the candidate?

Unintended consequences are just sloppy design.
If these are intended, then it's just poor design.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 26 Jul 2009 17:31:17 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> the same as a commit? 

No.

> What if user A starts
> as the 2nd commit?  What happens?

Same as if A copies from candidate to X, and from X to running.

> When is copy-config

I cannot see a use case.

> What does it even mean to trim the defaults from the candidate?

I think with-defaults for copy-config makes sense only when the target
is an URL.  And it makes sense only if the source is a data store!

> If these are intended, then it's just poor design.

Shouldn't this be specified in the with-defaults draft?

/martin