Subject: Re: [Netconf] comments on draft-ietf-netconf-with-defaults-06.txt

From: Kent Watsen <[email-masked]>
Date: Thu, 1 Apr 2010 11:51:49 -0700

> If someone inserts proprietary XML attributes that cause data nodes to
> be ignored in a standard NETCONF operations, I think the semantics of
> the operation have changed.
> 
> If our goal is interoperable standards for configuration, then we
> can't expect different implementations to do the same thing if the
> interpretation of an operation depends on proprietary XML attributes.

Agreed, but I'd assumed that the client would opt into using the attributes via passing some sort of capability-defined flag into the standard operations.  Isn't that what the extensibility model is for?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Apr 2010 14:35:14 -0700

Kent Watsen wrote:
>> If someone inserts proprietary XML attributes that cause data nodes to be ignored in a
>> standard NETCONF operations, I think the semantics of the operation have changed.
>> 
>> If our goal is interoperable standards for configuration, then we can't expect different
>> implementations to do the same thing if the interpretation of an operation depends on
>> proprietary XML attributes.
> 
> Agreed, but I'd assumed that the client would opt into using the attributes via passing some
> sort of capability-defined flag into the standard operations.  Isn't that what the extensibility
> model is for?
> 

no.

New capabilities (protocol, vendor, or YANG module) must not
contradict each other.  They are additive.

Technically, you could pepper your data models
with meta-data because the NETCONF operations are
required to work for any XML content.  Just don't use YANG.

For YANG modules advertised by the server,
(except for the anyxml data node type) there cannot
be any XML attributes returned in the NETCONF content.

There can also only be specific standard XML attributes
in the content, within an <edit-config> inline <config> element.
(Also applies to  <url> file input as well, for edit-config).

> Thanks, Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 1 Apr 2010 18:23:31 -0700

> contradict each other.  They are additive.

I think we're saying the same thing.  In this case, the module adds new syntax that MUST be used in order to trigger the new behavior.

> required to work for any XML content.  Just don't use YANG.

To alleviate any confusion, we're not hoping to use attributes for data; we'd only use them for metadata and processing directives.  As mentioned in Anaheim, I'll be submitting I-Ds for these things soon enough, so the WG can discuss details then

> be any XML attributes returned in the NETCONF content.

It's understood that the YANG syntax can't model attributes.  I guess YANG modules have to use prose to describe these things.  I don't know, what would you do if you wanted to add something like yang:insert? (assuming it didn't already exist)

But, going back to with-defaults, I still don't see an issue with allowing an explicit-server to annotate its report-all output - it just adds more value.  I know it's said that attributes are not supported, but I'm still hoping to understand why, when only used for metadata and processing-directives (not user config)...

As for the round-tripping concern, we could either:

1. disallow these annotations in <edit-config>
  - i.e. clients MUST cull those nodes out prior to edit-config
    or else expect rpc-error

2. allow the annotations in <edit-config>, but specify that servers MUST ignore the attributes
  - i.e. clients SHOULD cull those nodes out prior to edit-config
    or else server will create explicit values for those defaults)

3. allow the annotations in <edit-config> and let servers treat them like a processing-directive to skip creating explicit nodes for them. 
  - i.e. clients MAY cull those nodes prior to edit-config

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Apr 2010 18:53:10 -0700

>   - i.e. clients MAY cull those nodes prior to edit-config

I am not interested in adding any annotations to NETCONF PDUs.
I think the YANG modules sufficiently describe the content
and no additional standards are needed.

I do not think the NETCONF standard needs to add any support
for 'thin' clients.  That was never the intent of the with-defaults
draft.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Apr 2010 09:51:41 -0700

> I am not interested in adding any annotations to NETCONF PDUs.

That's evident, but it remains to be explained is *why* using attributes for metadata is an issue for the WG.  My guess is that this sentiment is a holdover from discussions regarding data (not metadata).   Anyone?

As another example, JUNOS allows nodes to be deactivated.  They're still in the configuration, but are effectively "grayed out".  When doing a <get-config>, we get back these nodes with an attribute inactive="true".  Juniper has defined a proprietary capability describing this modification to <get-config> as well as extensions to <edit-config> providing processing-directives to activate/deactivate configuration nodes.  We're been doing this for a long time - works great!

> and no additional standards are needed.

This is not always the case, sometimes the state is dynamic and thus can not captured in a spec (see above active/inactive example)

> for 'thin' clients.  That was never the intent of the with-defaults

No problem.  I'm fine with only supporting schema-aware clients.  Then can you please remove bullet-points 3 and 4 from your Introduction as well as the requirement for servers to implement report-all?  

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 05 Apr 2010 10:39:53 -0700

Kent Watsen wrote:
> That's evident, but it remains to be explained is *why* using attributes for metadata is an
> issue for the WG.  My guess is that this sentiment is a holdover from discussions regarding data
> (not metadata).   Anyone?
> 
> As another example, JUNOS allows nodes to be deactivated.  They're still in the configuration,
> but are effectively "grayed out".  When doing a <get-config>, we get back these nodes with an
> attribute inactive="true".  Juniper has defined a proprietary capability describing this
> modification to <get-config> as well as extensions to <edit-config> providing
> processing-directives to activate/deactivate configuration nodes.  We're been doing this for a
> long time - works great!
> 
> 

The NETCONF standard does not support inactive configuration.
It does not support pre-provisioning either.  I think you
should propose a standard solution.   You should work with
Juergen (IMO) to define operational data and inactive data.

If tagging the nodes with meta-data is the preferred solution,
after the WG agrees on the problem, then that is fine with me.

I would like a last-changed-time meta-data property, to support
a <time-filter> extension to <get> and <get-config>, since
we are piling on the wish-list.  :-)

> 
>> I think the YANG modules sufficiently describe the content and no additional standards are
>> needed.
> 
>> I do not think the NETCONF standard needs to add any support for 'thin' clients.  That was
>> never the intent of the with-defaults draft.
> 
> No problem.  I'm fine with only supporting schema-aware clients.  Then can you please remove
> bullet-points 3 and 4 from your Introduction as well as the requirement for servers to implement
> report-all?
> 

I do not see why.

The WG decided that if the client really cared which nodes were
explicitly set, it should just use with-defaults=explicit.

There is an expectation that a client can retrieve a config
with <get-config> and hand it back to the server in <edit-config>
or <copy-config> without making any changes to it.

As long as that remains true, you can add any XML attributes
to your own data models that you want.  Standard YANG data models
cannot have any proprietary XML attributes in them though.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Apr 2010 17:26:29 -0700

Andy,

I greatly appreciate your input on this

> we are piling on the wish-list.  :-)

Yup, we have this one too ;)

I don't intend to submit an I-D for inactive-configuration just now (maybe later this year) - I was just trying to show by example how using attributes for metadata is good

Sounds like you're OK with using attributes for metadata in principle, which is all I was after.   Since no one else is chiming in here, I'll conclude that the concern for attributes was/is limited to data and that a concern for using attributes for metadata has never been defined.

> explicitly set, it should just use with-defaults=explicit.

Well, that is going to be the basic-mode for any explicit server, so really the question is when would a schema-aware client ever NOT ask for report-all?  - I'm thinking never.  Perhaps it could be use to verify the accuracy of the vendor's schema, but that is really an activity the vendor must do prior to publishing their schema.  Vendors MUST validate the accuracy of their schema.

> or <copy-config> without making any changes to it.

I completely agree with this goal, and want to ratchet it up a little by adding that, when handed back, the server's final state is the same as it was when <get-config> was called.  Reasonable, isn't it?

But this is not the case when an explicit server is given the report-all config.  I know you said that clients should know better than to do that, but there are pathological cases that *will arise* and the negative impact on an explicit server is significant.  As a vendor that implements explicit config (how many others are there?), the downside risks seem to outweigh any value report-all (w/o tagging) adds

> cannot have any proprietary XML attributes in them though.
 
One thing I'm not clear on is the extent that a YANG module definition must itself use YANG - specifically for protocol modifications.  For instance, the with-defaults I-D has YANG statements like:

    augment /nc:get-config/nc:input {
        uses with-defaults-parameters;
    }

Are these *required* because YANG compilers MUST be 100% data-driven?  - or could this I-D have alternatively left it developer to read the RFC cited by the module's "reference" statement?  

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Apr 2010 11:58:52 +0200

On Mon, Apr 05, 2010 at 06:51:41PM +0200, Kent Watsen wrote:
> That's evident, but it remains to be explained is *why* using
> attributes for metadata is an issue for the WG.  My guess is that
> this sentiment is a holdover from discussions regarding data (not
> metadata).  Anyone?

Since you ask for opinions...

I am not much concerned how metadata is encoded (attributes seem to be
a reasonable choice) as long as metadata does not change any semantics
of standard protocol operations. That said, I do see lots of practical
value in having metadata around. But I of course prefer a discussion
in order to figure out whether it is possible to standardize some of
the metadata instead of having to deal with several vendor extensions
for likely similar things.

/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/>