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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Nov 2008 23:00:29 +0100

> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs.

I agree - I have been pretty surprised to see with-defaults on the RPC
layer and not the operations layer - looks like a layer violation to
me.

/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/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Nov 2008 23:00:29 +0100

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 14:04:22 -0800

> layer and not the operations layer - looks like a layer violation to

The reason for this is that the <rpc> element already has
to accept any XML attribute and return it unchanged.
It was the path of least resistance, especially for
a vendor extension.

For a standard, normal element-based parameters would
be the most YANG-ish thing to do.

> /js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 14:04:22 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 23:34:07 +0100 (CET)

> be the most YANG-ish thing to do.

I agree.

The problem is that the XSD in 4741 is not an open schema in that it
does not allow unknown elements or attributes (with the exception of
<rpc>).  I think that this was not the intention with the spec, and
that it should be clarified in 4741bis.  I think the intention was
that capabilities could add parameters to the operations, even though
not explicitly allowed by the XSD.  We can either make the XSD
explicitly open (that'll be ugly though - XSD 1.1 anyone ;-), or we
can just state this in text.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 23:34:07 +0100 (CET)

I agree.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 23:36:58 +0100 (CET)

> Otherwise there is no way to guarantee that you don't get

+1

And we should allow for devices which cannot distinguish between
defaults and other values to not have to support
with-defaults="false".  I think it's better that they don't implement
it, rather than fake it.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 23:36:58 +0100 (CET)

+1

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Nov 2008 17:46:08 -0500

>layer and not the operations layer - looks like a layer violation to

I agree.  This comment has been made a number of times with the
previous draft, but the new draft continues to put it on the <rpc>
element.  While I understand this must change to match the WG's
opinion if this document become a WG doc, it still surprising.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Nov 2008 17:46:08 -0500

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 27 Nov 2008 10:01:27 +0100

Hello,
I agree that the proper place for the with-defaults attribute would be the operation, however 
we need WG consensus that 4741 does allow this. As I see it the following people agree with the 
statement:
"4741 allows new RFCs to add attributes to the XML elements in the XSD schema."
Phil, Martin, Balazs, Sharon, Jurgen
Please state if I am wrong !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Opinion by others?

This raises a number of other questions:
1) If attributes can be added, can new elements be added as well?  I would say yes.
2) If we agree that standard track RFC can add stuff, can individual agent, manager SW also add 
attributes and still claim compliance? E.g. If they define a proprietary capability.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 27 Nov 2008 10:01:27 +0100

Hello,

Opinion by others?

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Nov 2008 10:16:38 +0100 (CET)

> 1) If attributes can be added, can new elements be added as well?  I would say

Yes.  And I agree with Andy that with-defaults should probably be an
element rather than an attribute.

> 2) If we agree that standard track RFC can add stuff, can individual agent,
> manager SW also add attributes and still claim compliance? E.g. If they define
> a proprietary capability.

Yes.

The WG did talk about this issue at some point (Vancouver?), and IIRC
there was consensus that a capability can *add* to existing
operations, but there was not consensus that a capability can *change*
existing behavior.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Nov 2008 10:16:38 +0100 (CET)

Yes.

/martin