Subject: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Jun 2010 16:45:29 +0200

On Wed, May 26, 2010 at 09:20:43AM +0200, Bert (IETF) Wijnen wrote:

> This is a(nother) formal WG Last Call for this  this document.
> Please review and comment BEFORE June 6th 2010.

Here is my review of draft-ietf-netconf-with-defaults-08. Sorry for
being a day late but the weather last weekend was just too nice to sit
in front of my computer...

I still believe the announcement of the basic-mode should be part of
RFC 4741bis so that _all_ RFC4741bis implementations announce their
basic default handling mode.

I regret that we do not solve the more general problem how we report
operational state data but instead solve via a new tagging mechanism
only for default value identification problem, which I consider a
special case of operational state data.

Here are all the other little comments I have on the -08 version. I
have tried to be constructive, proposing concrete rewordings for some
pieces of text. These text messages are meant to help the editor and
make my change request clear but other wordings might do equally well;
take my wording proposals just as a suggestion.

a) p4 says:

   [...] Part of the configuration data may
   not be set by the NETCONF client, but rather by a default value from
   the data model.

   Reading this as someone who prefers explicit mode and considers
   defaults as operational state, this sentence is not correct. In
   explicit more, the default is not part of the explicit configuration.

b) p4: s/can be e.g.,/can be obtained from e.g.,/

c) p4 says:

   Default data:  Data considered by a particular server to contain a
      default value.  Default data is not kept in a configuration
      datastore.

   Again, the last sentence is not true for an explicit server.

d) p4: s/an actual management operation/an explicit management operation/

e) p5: I suggest to remove the following sentence:

       [...] The nodes that are returned in this case are
       the only nodes the server considers to exist in the datastore.

   I do not know what 'this case' refers to nor to I think this
   sentence is always correct and it seems the sentence is not 
   needed in the first place.

f) p5: s/<edit-config> 'operation'/operation attribute of the <edit-config> operation/

   The motivation is to align with the language used in RFC 4741.

g) p6: replace this sentence

   OLD

   In all these cases the NETCONF client will need default data as part
   of the NETCONF <rpc-reply> messages.

   NEW

   In all these cases, the NETCONF client will need a mechanism to
   retrieve default data from a NETCONF server.

   Motivation: I think we should avoid talking about <rfc-reply>
   messages since this whole document is an extension of some
   operations of the operations layer.

h) p6: s/in certain NETCONF <rpc-reply> messages//

   Same motivation as above.

i) p7: s/'create' operation/'create' operation attribute/
       s/'delete' operation/'delete' operation attribute/

   Motivation: Align with RFC 4741 terminology. Note this shows
   up twice on p7.

j) p7: I think we need to be more explicit about the tagging:

   OLD

   [...] If all NETCONF sub-operation
   parameters are valid, then the server will treat a tagged data node
   as a request to return that node to default data.

   NEW

   [...] If all NETCONF sub-operation
   parameters are valid, then the server will treat a wd:default="true" tagged data node 
   as a request to return that node to default data.

k): p7/p8: I am confused by this text:

   If the data
   node within the NETCONF message contains a value in this case, it
   MUST be equal to the schema default value.

   I think "this case" can be dropped. I am not sure whether the
   intention was to allow an edit-config without a value like this:

   <mtu wd:default="true"/>

   Anyway, if a value is provided and does not match the default, it
   would be nice to spell out which error is to be returned.

   The same sentence can be found at the end of 2.3.3 on page 9.

l) p8: s/'create' operation/'create' operation attribute/
       s/'delete' operation/'delete' operation attribute/

   Motivation: Align with RFC 4741 terminology. Note this shows
   up twice on p8.

m) p9: Reword this sentence:

   OLD

   All data nodes that are explicitly set data MUST be saved in non-
   volatile storage.

   NEW

   All data nodes that have been explicitly set MUST be saved in non-
   volatile storage.

m) p9: s/NETCONF operation request messages/NETCONF operations/

n) p9: This seems to be incorrect now that we have tagged mode:

   The <with-defaults> parameter contains one of the three basic mode
   enumerations defined above, to request that the retrieval operation
   be performed using the specified defaults handling basic mode.

o) Perhaps section 3.1 should become a sub-section of section 2 - this
   would also fix the above sentence. In particular, tagged report all
   also impacts the edit-config operation and not just "Retrieval of
   Default Data", the heading of section 3. The only difference is
   that the document kind of disallows report-all-tagged as a basic
   mode. I am also not sure why this restriction is there - I would
   likely prefer a report-all-tagged over a report-all basic mode
   server.

p) p9: s/variant of 'report-all'/variant of the 'report-all'/

q) p9: broken sentence:

   OLD

   A server which supports 'report-all-tagged' MUST also accept the 'wd:
   default' XML attribute it is present within configuration input to
   the <edit-config> or <copy-config> operations.

   NEW

   A server which supports 'report-all-tagged' MUST also accept the 'wd:
   default' XML attribute within configuration input to
   the <edit-config> or <copy-config> operations.

r) s/is part of NETCONF <rpc-reply> messages/is returned by NETCONF operations/

s) p11: Why are these SHOULDs and not MUSTs?

   If an unsupported value is used, the NETCONF server MUST return an
   <rpc-reply> with an <rpc-error> element.  The <error-tag> SHOULD be
   'invalid-value', and the <error-app-tag> SHOULD be 'with-defaults-
   mode-not-supported'.

t) p12: Is this true for all basic modes?
  
   [...] If the wd:default attribute is present and set to 'true',
   then the server MUST treat the new data node as a request to return
   that node to its default value (i.e., remove it from the database).

u) p12: unclear context:

   If this editing mode is used, then ...

   It is unclear to me what "this editing mode" refers to. I suggest
   to be more explicit.

v) p12: s/'nc:operation' attribute/operation attributes/

w) p13: Should we make the prefix ncwd so that all NETCONF related
   prefixes start with nc? The monitoring ID currently uses ncm. Note
   that the prefix also shows up in the IANA considerations.

x) p14: Attempt rewrite of the first paragraph of the description:

   OLD

     "This module defines a capability-based extension to the
      NETCONF protocol that allows the NETCONF client to control
      whether default values are part of NETCONF
      <rpc-reply> messages or <copy-config> output to the target URL.

   NEW

     "This module defines an extension of the NETCONF protocol that
      allows a NETCONF client to control how default values are
      handled by the <get>, <get-config>, and <copy-config> NETCONF
      operations.

y) p14: with-defaults-mode description rewrite:

   OLD
         "Possible modes to report default data in
          rpc-reply messages.";

   NEW
         "Possible modes to report default data.";

z) p17: I suggest to simplify the security considerations:

   OLD

   The 'with-defaults' capability gives client control over the
   retrieval of particular types of XML data from a configuration
   datastore.  They only suppress data that can already be retrieved
   with the standard protocol operations, and do not add any data to the
   configuration datastore.

   NEW

   The 'with-defaults' capability gives clients control over the
   retrieval of default data from a configuration datastore. The
   security consideration of [I-D.ietf-netconf-4741bis] apply.

A) p18ff: I suggest to s/itf-status/status/g since the prefix is
   not used consistently and just adds noise to the examples.

B) p23: s/dafault/default/

C) p1: An attempt at rewording of the abstract to avoid talking about
   <rpc-reply> messages:

   OLD

   [...]
   In other situations the NETCONF client will need this data as part of
   the NETCONF <rpc-reply> messages.  Not all server implementations
   treat this default data the same way.  This document defines a
   capability-based extension to the NETCONF protocol that allows the
   NETCONF client to identify how defaults are handled by the server,
   and control whether default values are part of NETCONF <rpc-reply>
   messages or <copy-config> output to a file.

   NEW

   [...]

   In other situations, the NETCONF client will need default data
   returned as part of the result of NETCONF configuration retrieval
   operations. Furthermore, not all server implementations treat
   default data the same way.

   This document defines a capability-based extension of the NETCONF
   protocol that allows clients to discover how defaults are handled
   by a NETCONF server. In addition, the extension introduces an
   additional parameter that enables clients to control how default
   values are handled by <get>, <get-config>, and <copy-config>
   NETCONF operations.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Jun 2010 12:04:41 -0700

> basic default handling mode.

I don't think the RFC number changes the conformance
requirements.  The IESG charters units-of-work,
reviews/approves units-of-work, and the IETF community
has to deal with the distributed information.

> special case of operational state data.

I agree there is still a lot of work left to do wrt/ configuration
and operational state.  However, this unit-of-work is not
designated to contain that functionality.  I'm sure our A-Ds
would not mind if some people wrote an I-D to start this work,
indicating that there is sufficient interest and resources
to work on the problem.  Until there is a draft to discuss,
there isn't much for the IETF to do.

I prefer a new parameter to existing operations,
like <state-filter>, instead of a new <get-operational>, or
some other special operation(s).  But we are not nearly
ready to discuss solutions yet.  (What about set-state?)

> take my wording proposals just as a suggestion.

I am working on all your comments now...

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Jun 2010 21:18:02 +0200

On Tue, Jun 08, 2010 at 09:04:41PM +0200, Andy Bierman wrote:
> requirements.

With-defaults is not mandatory to be implemented and as a consequence
a NETCONF server does not have to announce its default behaviour. At
the same time, with the with-defaults document states:

   It can be important for a client to know exactly how a server
   implementation will handle default data.  There are subtle
   differences in some protocol operations where the defaults handling
   behavior of the server will affect the outcome of the operation.

The simplest and cleanest solution would be to fix this situation in
4741bis. Your statement about RFC numbers misses the point. And no, I
do not want to discuss this here again.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Jun 2010 12:41:05 -0700

> do not want to discuss this here again.

Well, you brought it up again.
If the WG agreed to MUST implement, it would
not matter which RFC contained that text.
The WG only agreed to SHOULD implement.
I don't mind changing SHOULD to MUST,
but that consensus call needs to be made by the co-chairs, not us.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Jun 2010 21:58:13 +0200

> Well, you brought it up again.

I wanted to make it clear to the chairs where I stand. I do not want
to discuss things again from scratch.

> not matter which RFC contained that text.

My understanding is that the announcement of the basic mode is a no
brainer implementation wise. Supporting additional parameters of 4741
operations can be more work. Hence I liked Lada's compromise proposal
to move the basic mode announcement into 4741bis and leave the new
with-defaults parameters as an extension to 4741bis.

> but that consensus call needs to be made by the co-chairs, not us.

For the chairs to make concensus calls, they need to know opinions of
the WG members. This is why I restated my opinion. I think we both
understand the IETF process and I think we both understand the
technical issue on the table.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Jun 2010 13:29:50 -0700

On 06/08/2010 12:58 PM, Juergen Schoenwaelder wrote:
> ...

Phil and I disagree with you and Lada.

A vendor chooses which RFCs it wants to support.
I understand you want to force a server that supports
base:1.1 to also advertise its basic-mode.

I don't agree it is that important or the coupling is warranted.
A server that implements the with-defaults spec MUST advertise
its basic-mode.

There is no reason a base:1.0 server could not advertise its
basic mode as well as a base:1.1 server.

If the functionality in the RFC is really needed, it will get implemented.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2010 07:00:01 +0200

> base:1.1 to also advertise its basic-mode.

This seems to be a fair summary. And I have not seen a technical
reason so far why a 1.1 server should not be forced to announce its
basic mode.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 07:49:33 +0200

> reason so far why a 1.1 server should not be forced to announce its

Yes, I too don't see why this relatively minor change cannot be done now
and why it should cause any problems to implementors of 1.1.

On the other hand, without the basic default mode advertisement the
application of the concept of defaults in YANG would be tricky at best.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Jun 2010 08:04:01 +0200 (CEST)

Hi,

> application of the concept of defaults in YANG would be tricky at best.

I do not think so.  There are a couple of common use cases.

 1.  create a new list instance (or p-container) with children with
     default in the YANG model - just create without the default value
     and all servers will do the right thing.

 2.  set a new value other than the default - just use the 'merge'
    (which is the default) operation and all servers will set the new
    value, regardless of previous state.

 3.  reset to default - use the new 'remove' operation and all servers
     will have the default value in use, regardless of previous state.

Note that (3) requires the new proposed 'remove' operation, so it
works only with 1.1 servers.

There are corner cases where the server's behavior varies between the
different basic modes, but these are easily avoided by client
programs, as shown above.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2010 08:12:42 +0200

> I do not think so.  There are a couple of common use cases.

So you are saying the text I quoted form the ID is wrong?

Different servers may return different configs when I configure
something that includes defaults. I think it is fair to let clients
know upfront what they can expect instead of letting clients discover
the default handling behaviour by interpreting observed behaviour,
especially if the implementation cost is close to zero on a server.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 08:27:05 +0200

> programs, as shown above.

The corner cases may cause major headaches, so if that little bit of
information from the server can help to avoid them, I think it's worth
it. If we accept the modal behaviour as a fact of life, it is IMO an
absolute necessity that all parties be sure about which mode is used.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Jun 2010 08:34:46 +0200 (CEST)

>    behavior of the server will affect the outcome of the operation.

No, this is correct.  There _are_ subtle differences.  But with the
addition of the 'remove' operation, these differences are easily
avoided in most common cases.  (In fact, it is probably easier to
write generic client code that works on all servers instead of having
to switch on the basic mode.)

Are there any use cases where the client cannot do the right thing
without knowing the basic mode?

> especially if the implementation cost is close to zero on a server.

Agreed.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 09:07:03 +0200

> to switch on the basic mode.)

You are assuming that everybody writes clever and bug-free programs. We
now have the opportunity to decrease the entropy by an explicit protocol
signalling, which decreases the expected level of cleverness on the
client side.

Moreover, the reason why something works for one server and fails for
another will be evident from the protocol operation, which is IMO a very
good thing.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Jun 2010 09:34:27 +0200 (CEST)

> signalling, which decreases the expected level of cleverness on the

If you write complex code that adjusts its behavior depending on the
server, when you can write simple code that works for all servers, you
probably increase the opportunity for bugs...

But don't get me wrong.  I think :with-defaults is useful.  I'm just
saying that your statement that handling defaults is "tricky at best"
is not correct - provided we add the 'remove' operation.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2010 09:45:23 +0200

> is not correct - provided we add the 'remove' operation.

This is kind of interesting - you argue that the difference in the
default handling requires us to add the 'remove' operation while at
the same time you seem to argue against announcing the basic default
handling mode, which has zero costs implementation wise. So obviously,
what happens if you use 'delete' depends on the basic mode. Hence, I
think it is fair to announce what the basic mode is.

Your argument seems to be one should not use protocol features where
the basic-mode makes a difference. The logical consequence would then
be for me to remove or deprecate those operations. If we leave these
operations in, I think it is just fair if the server announces what
these operations will do.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Jun 2010 09:54:50 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> handling mode

No, I'm arguing that it is not tricky to handle the different
behaviors in edit-config.

> which has zero costs implementation wise. So obviously,

And I agree.  I have never argued that we should not do
:with-defaults.  Since there are differences, the server should let
the client know its basic mode.  But in real code, I doubt it will
have much impact.  If you know a use case where it will, please prove
me wrong!

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 10:00:55 +0200

> is not correct - provided we add the 'remove' operation.

It definitely is tricky, as long as there are operations where the
client cannot predict the outcome beforehand. Imagine that e.g. SQL
worked this way.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Jun 2010 01:06:01 -0700

> behaviors in edit-config.

I do not see the importance of special-case code on the client
to deal with creating and deleting nodes that have a default
value.  The client has to check if the data node exists
first for a node without a schema default.

I don't know why an application would bother with lots
of special-case (not tricky) code when 'merge' and 'remove'
solve the problem in every usage scenario.  Once you get that
code working, why bother with the special-case code?

> have much impact.  If you know a use case where it will, please prove

I agree.  I think the client has to go out of
its way to turn with-defaults basic-mode advertisement
into a critical piece of information.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Jun 2010 10:24:28 +0200 (CEST)

> > behaviors in edit-config.

I meant "it is not tricky to handle the different behaviors of servers
in edit-config, without special code, since the simple, generic code
will work for all servers".

So we agree.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2010 10:29:42 +0200

On Wed, Jun 09, 2010 at 10:00:55AM +0200, Ladislav Lhotka wrote:
> Martin Bjorklund p????e v St 09. 06. 2010 v 09:34 +0200:

I agree with you but others say "as long as there is a way to work
around it, we can save the announcement of the basic-mode in the hello
exchange". I do not buy this argument since the result of a simple
get-config depends on the basic-mode - its as simple as that. If I
will have boxes from Juniper and Cisco, they will behave differently
and I think it is just fair that these boxes tell operators what
behaviour to expect.

The bottom line is that NETCONF servers behave differently. Lada and I
like to mandate that NETCONF 1.1 servers announce these differences
during the hello exchange to make the behaviour one can expect
obvious. Others like to hide the differences, leaving it to the
introduction of additional operations and smart client design to take
care of the differences (even though that does not change the fact
that a plain get-config returns different results for the same config
on different basic-mode servers).

I do not know what the chairs will read out of this discussion. At
least this split of opinions in the WG needs to be carefully and
fairly explained in the protocol writeup for the IESG so that the IESG
has a decent understanding of the situation in the WG.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 10:45:39 +0200

> code working, why bother with the special-case code?

Then remove the "create" and "delete" operations, or restrict them e.g.
to "create-list-entry". How can a poor developer know just by reading
RFC4741bis that "merge" is OK but "create" may not be?

create:  The configuration data identified by the element
   containing this attribute is added to the configuration if
   and only if the configuration data does not already exist in
   the configuration datastore.  If the configuration data
   exists, an <rpc-error> element is returned with an
   <error-tag> value of data-exists.

The problem here is that the client cannot always determine from a
retrieved configuration whether "configuration data exists" or not, as
someone who hasn't followed the discussions in the ML might easily
assume.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Jun 2010 13:01:20 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> exchange".

I have never said that.  I agree that with-defaults is useful, and I
have no objections to moving the basic-mode advertisment into
4741bis.

My only point is that writing client code without knowing the basic
mode is not as tricky as you might think.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 13:32:38 +0200

> have no objections to moving the basic-mode advertisment into

OK, so we've got (at least) three supporters of this change.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Jun 2010 05:41:08 -0700

> OK, so we've got (at least) three supporters of this change.

I would really like to understand why you think rearranging the
RFCs will change the conformance. Currently, the server SHOULD
advertise the basic-mode. Moving the text to another RFC is not
going to change that SHOULD. It can change from a SHOULD
to a MUST, regardless of the RFC number -- but the WG has not
agreed the server MUST advertise this capability.

I do not agree with either of your proposals:
1) move the basic-mode advertisement to 4741bis
2) change conformance from SHOULD to MUST

I fail to see the point of (1), with or without (2).
Balazs, Phil, and I have stated we are against moving the
RFCs around. Nobody seems to care if and when this work
ever gets finished, not that being 150% late counts in the IETF.

Why is it even relevant that conformance to 4741bis be
considered here? Why can't a 1.0 server advertise
the with-defaults capability, not just a 1.1 server?
(Some implementations of 4741 already do this.)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2010 16:01:29 +0200

On Wed, Jun 09, 2010 at 02:41:08PM +0200, Andy Bierman wrote:
 
> RFCs around.

If the basic-mode advertisement is part of 4741bis, then a 4741bis
compliant server has to announce its basic mode.

A MUST in WD will not establish a MUST for a 4741bis compliant server
- unless we state a "MUST also implement WD" in 4741bis and we create
a wired dependency between two documents.

> Nobody seems to care if and when this work ever gets finished, not
> that being 150% late counts in the IETF.

The big delay is caused by all the discussions we had and still have
around defaults, not the edits.  Anyway, WD won't appear as an RFC
before 4741bis appears as an RFC since WD normatively depends on
4741bis.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 17:53:23 +0200

> advertise the basic-mode. Moving the text to another RFC is not

But SHOULD/MUST every implementor of RFC4741bis also take into account
the with-defaults spec? If not, the "SHOULD advertize the basic-mode" is
quite moot.

> I fail to see the point of (1), with or without (2).

Two points:

1. All important behaviour of a NETCONF server is stated in a single 
   document.

2. RFC4741bis tries to avoid touching the defaults-related issues but 
   then important statements like "configuration data exists" are quite 
   vague. I think RFC4741bis should face that issue, explain the 
   defaults-handling modes and what "data existence" really means in 
   each of the modes, and also stipulate the basic-mode advertisement.

> Balazs, Phil, and I have stated we are against moving the

I haven't heard anything from Balazs since quite a long time.

> ever gets finished, not that being 150% late counts in the IETF.

Getting it right is important, too.

> (Some implementations of 4741 already do this.)

What if a server does NOT advertise with-defaults? Then the basic-mode
cannot be signalled. On the other hand, if the server does advertise
with-defaults, it also has to accept the <wd:with-defaults> parameter,
right? This is something not everybody is ready to do whereas the basic
mode advertisement is a no-brainer.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Jun 2010 09:16:13 -0700

> the with-defaults spec? If not, the "SHOULD advertize the basic-mode" is

Martin and I have pointed out why knowing the basic-mode
is not critical, especially when we add the 'remove' operation
that nobody has objected to adding.

The assertion that "The client MUST know the basic-mode"
is false.

> 1. All important behaviour of a NETCONF server is stated in a single 

This is a subjective assertion and cannot be proved.
Not everybody agrees basic-mode advertisement is important.

> Getting it right is important, too.

That's what the IESG keeps telling itself to justify
the awful track record.

> mode advertisement is a no-brainer.

As Phil pointed out many times -- without the basic-mode advertisement
you can retrieve a node and know for sure if create/delete should
work. This is what has to happen for nodes without schema-defaults,
and for multi-app NM environments anyway, so the code is already there.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Jun 2010 18:33:34 +0200

> that nobody has objected to adding.

Without knowing the basic mode the client has to be careful with some
operations that seem perfectly legal, and RFC4741bis provides no
guidelines on this, simply because it is not able to explain the
problem.

Lada
  
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Jun 2010 09:55:06 -0700

> guidelines on this, simply because it is not able to explain the

Those operations require care - by design.
When 4741 was written, the intent of create/delete was for
these operations to be picky -- Sharon really insisted on this.
Not many people really cared, or understood that years later
implementations would use different database designs
wrt/ defaults that would impact create and delete.

Now we have implementation experience, and we know that
merge/remove will fix the problem by providing the same basic
functionality as create/delete, except it will work on every server
the exact same way.

Andy

---

From: "t.petch" <[email-masked]>
Date: Wed, 9 Jun 2010 18:32:05 +0200

Make that four supporters of the change.

Tom Petch

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 09, 2010 1:32 PM
Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt

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