Subject: [Netconf] Commons on with-defaults Draft

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 26 Nov 2008 12:56:49 -0500

Hi

As I said in Minneapolis, I believe this work is important and the
current draft is a reasonable starting point. Here are the more detailed
comments I promised.

Major
-----

1. This capability needs to apply to all operations where it makes
sense. The current text, while not strictly speaking precluding this,
might be a bit misleading.  It talks primarily around <get> <get-config>
and <edit-config>. In particular, I'd like to see section 2.1 second
paragraph say something more like each operation SHOULD specify how this
capability affects them.

2. The with-defaults argument should go on the operation itself.
<get-config with-defaults="true"> <foo-bob with-defaults="false">.  From
reading section 7.1 there seems to be some sort of issue with placing it
there, but I don't fully understand it. Putting the parameter on the
<rpc> portion will change the way the operations need to be parsed and
handled by the system doesn't it? Perhaps I'll play a bit with the XSDs.

3. The behaviour really needs to be
  - no argument: then default behaviour of system (whether to send
defaults or not)
  - with-defaults="true": then default values are sent
  - with-defaults="false": then default values are not sent
Otherwise there is no way to guarantee that you don't get
default-values.

Medium
---------

4. In the abstract or in the introduction it should be explained that
some default values are set in the Schema (XSD, YAM, RNG, etc) many
others are not because they change between different implementations and
potentially different versions of the machine. While in my experience
there are more of the latter type than those in Schema, we probably
should not go as far as saying that.

The first paragraph of the Introduction (section 1) would be a good
place to add this.

5. A useful concept in our internal discussions of this topic is the
difference between user set of system set data. This might be better
than the terminology currently in section 1.1.2.

6. I think we should be careful with the discussion of the default
behaviour of the system with respect to showing defaults. I think we
should acknowledge in a single section of the document what forms this
might take (return them always, return them when explicitly set by the
user and never return them) and then only make reference to this default
behaviour as appropriate (like the behaviour we get when the
with-defaults parameter is omitted). This difference and
unpredictability in behaviour is because we underspecified the behaviour
in RFC 4741 rather than something we need to preserve once this
capability is supported.

The first two paragraphs of section 2.2.1 can be replaced by a couple
sentences indicating that RFC 4741 didn't specify a specific behaviour
and neither does this one unless the parameter is given.

7. I'm not sure what to do with the XSD. How does this get used while
validating commands?

8. In the security considerations section, we may want to add something
around the fact that if you can see default values for the part of the
system you have access to, than it provides insight into what values
might be used (as defaults) into parts of the system or similar systems
that you don't. For example, if the default port is 23434 when I learn
this I might be able to use this to launch attacks.

Nits and Editing
-----------------

9. The document uses agent and manager terminology instead of client and
server.

10. The document uses rpc reply and rpc instead of <rpc-reply> and
<rpc>.

11. In section 2.1, replace "The NETCONF
   agent MUST also indicate it's basic behavior, whether it sends
   default data in the absence of any specific request from the NETCONF
   manager." with "The NETCONF
   agent MUST also indicate its basic behavior, whether it sends
   default data in the absence of any specific request from the NETCONF
   manager."

12. What are management agents? (section 2.1.1)

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf