Subject: [Netconf] quick comment on NETCONF Light draft

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jan 2012 16:39:10 -0800

Hi,

I was looking over this draft:

http://www.ietf.org/id/draft-schoenw-netconf-light-01.txt

I can agree with the problem statement:
There is a need for a constrained server which supports a limited subset of NETCONF operations.

I don't agree with the solution, since it is not backward-compatible with
any version of NETCONF.  A base:1.0 or base:1.1 peer will simply terminate
the session when a NETCONF Light peer does not advertise either of these capabilities.

YANG deviations can be used to fully describe the operations subset that a server implements,
and this is backward-compatible with the current version of NETCONF.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Jan 2012 23:33:45 -0500

Andy Bierman writes:
>A base:1.0 or base:1.1 peer will simply terminate

Haven't read the draft, but doesn't the Postel principle hold here?
IIRC JUNOS doesn't require the <hello> at all.  It was mostly useless
in RFC4741 NETCONF.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jan 2012 23:33:25 -0800

On 01/18/2012 08:33 PM, Phil Shafer wrote:
> IIRC JUNOS doesn't require the<hello>  at all.  It was mostly useless
> in RFC4741 NETCONF.
>

No, because the SSH framing is determined by the base:1.x capability advertised.
This isn't the only MUST that I've seen server implementations ignore.

But even if the solution-space argument "it doesn't matter to the client" is used,
I could argue "just use the standard correctly and send operation-not-supported
errors -- a new capability + features does not help at all".

There is already a standard solution that will work that is backward-compatible
so why bother inventing a new solution that is not backward-compatible?
The "Don't waste our time" Principle holds here.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2012 08:43:57 +0100

> the session when a NETCONF Light peer does not advertise either of these capabilities.

And this is correct. A NETCONF Light server does not implement
base:1.0 nor base:1.1 - so announcing it would be bad.
 
> YANG deviations can be used to fully describe the operations subset
> that a server implements, and this is backward-compatible with the
> current version of NETCONF.

There are two concerns with this:

1) YANG says deviations can't be standardized:

   Deviations define the way a device or class of devices deviate from a
   standard.  This means that deviations MUST never be part of a
   published standard, since they are the mechanism for learning how
   implementations vary from the standards.

2) Can we reasonably expect all client implementations, including
   scripts, to handle deviations correctly? If not, announcing the
   base:1.x with deviations will likely lead dumb clients to assume
   the server speaks NETCONF while it does not. By using a different
   capability, it is explicit from the start that the device
   implements NETCONF Lite.

I believe it is more robust to use a different capability + features
than using the NETCONF base:1.1 capability + deviations.

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2012 09:03:13 +0100 (CET)

> IIRC JUNOS doesn't require the <hello> at all.  It was mostly useless

I think Andy refers to the client - to the client, <hello> is not
meaningless.

Anyway, I don't think it is a problem if this new protocol is not
compatible with old clients.

I have another comment.  The draft needs to discuss the transport
layer.  RFC 6242 uses the :base capability to determine framing, and
since this protocol doesn't advertise :base, it is not clear what a
client should do.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 00:37:33 -0800

>     implementations vary from the standards.

The purpose of deviations is to describe to the client what details in the API
are different than the 'contract'.  YANG deviations are designed and included in the standard
for exactly the purpose that a NETCONF light server needs.

>     capability, it is explicit from the start that the device

Yes, we can expect clients that implement YANG correctly to understand deviations.

IMO this 'light' solution is a hack -- a client would be better off ignoring all of this
and just going by the operation-not-supported errors it gets back.
A new client would have to be coded to look for the special new URI
instead of the old ones, then apply the features from the fake 'light' module
to the ietf-netconf module, and use the ietf-netconf module XML namespace as well.

Or, an existing client could ignore all the deviations and URIs
and just attempt operations to see if they worked.

> than using the NETCONF base:1.1 capability + deviations.

IMO, robust would be if the solution did not break with existing versions of the standard.
A non-backward-compatible solution is not robust at all.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2012 10:09:41 +0100

On Thu, Jan 19, 2012 at 12:37:33AM -0800, Andy Bierman wrote:
 
> IMO this 'light' solution is a hack -- a client would be better off
> ignoring all of this and just going by the operation-not-supported
> errors it gets back.  A new client would have to be coded to look
> for the special new URI instead of the old ones, then apply the
> features from the fake 'light' module to the ietf-netconf module,
> and use the ietf-netconf module XML namespace as well.
>

Some people prefer to know upfront what they can expect. Lets overcome
the old SNMP idea to try and if something expected is not there assume
there is smart code to try something else instead.

I prefer a yangcli that _upon_startup_ says "sorry the remote end does
not do NETCONF". Much better than a yangcli that fails badly in the
middle while I am trying to get a job done. And if yangcli gets
extended to support NETCONF Light, it can tell the user upon startup
that its talking to a NETCONF Light server and adapt the commands
offered to the user to what the server supports. Feature negotiation
is in my view much better than failing unexpectedly. Of course, your
mileage can vary.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2012 10:16:06 +0100 (CET)

> there is smart code to try something else instead.

+1

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2012 12:55:31 +0100

> since this protocol doesn't advertise :base, it is not clear what a

Here the proposed fix:

OLD:

    NETCONF Light uses the NETCONF message framing as defined in
    [RFC6241].  In particular, it uses the same XML encoding and XML
    namespace.

NEW:

    NETCONF Light uses the NETCONF message format as defined in
    [RFC6241].  In particular, it uses the same XML encoding and XML
    namespace.  Furthermore, NETCONF Light uses the same NETCONF
    transports such as NETCONF over SSH as defined in [RFC6242].

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2012 12:59:55 +0100 (CET)

>     transports such as NETCONF over SSH as defined in [RFC6242].

Unless you want to use the old SSH framing, the problem is this in 6242:

   If the :base:1.1 capability is advertised by both
   peers, the chunked framing mechanism (see Section 4.2) is used for
   the remainder of the NETCONF session.  Otherwise, the old end-of-
   message-based mechanism (see Section 4.3) is used.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 04:22:54 -0800

> there is smart code to try something else instead.

This isn't about SNMP.
It is about using the YANG deviations that already exist for the
purpose that they were designed for, or ignoring them, and producing
new solutions that do not work with the existing standard.

> is in my view much better than failing unexpectedly. Of course, your

yangcli already supports deviations in data model modules.
It would be much easier to complete that work for the protocol operations
than it would to re-engineer for a new hello exchange, and map the
fake light 'features' to the ietf-netconf module.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 04:38:48 -0800

On 01/19/2012 01:16 AM, Martin Bjorklund wrote:
> Juergen Schoenwaelder<[email-masked]>  wrote:

If the code was smart, it would pay attention to the server <hello> instead
of ignoring it.  My comment above is pointing out that if the client is
not going to use the deviations, why would it bother to use this new capability
plus all the fake YANG features (they apply to the ietf-module, not the light module)?

Processing all the <hello> tells you what the server may do in advance,
if implemented correctly, for 1 specific error-tag (operation-not-supported).
The client still needs to be coded to handle all the other error-tags that can occur,
such as in-use, resource-denied, operation-failed.  In a way, it is a myth
that the <server> hello solves any real coding problems in the NMS.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2012 14:29:41 +0100

> new solutions that do not work with the existing standard.

There is a standard that says:

We are compliant with that. ;-)

> fake light 'features' to the ietf-netconf module.

There is no new hello exchange. We just announce a different version
of NETCONF - that has happened before.

/js

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2012 10:33:18 -0500

Andy Bierman writes:
>of ignoring it.

The vast majority of our client connections aren't smart.  And they
don't want to be.  They've been given a XML-encoded RPC and want
to issue it to the remote side and pass the XML-encoded results
back to the user.  The idea is that a NETCONF client _CAN_ be smart,
not that it _MUST_ be smart.

But if we're doing a "light" version, can we do something to address
connection startup time?  ssh startup is expensive and then we do
our hello handshake on top of that.  If we're being light and not
worrying about backwards compatibility (which seems strange), can
we make the <hello> officially optional, since clients can use the
RPC (get-hello?) get the hello contents?

I keep noodling our resident ssh guy to come up with a means of
caching keys between connections to reduce the exchange ssh does
at startup.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2012 10:38:07 -0500

>I think Andy refers to the client - to the client, <hello> is not

My experience may be different, since my devices are more permanent
and don't DHCP, but...

To most of our clients, the hello is meaningless.  The OSS system
above them knows what the server device is, has generated configuration
for it, and wants the client library to commit that code.  The
typical client just wants to open the connection, toss the RPCs,
and return something useful to the caller.  Except for a sanity
check (to see that the device hasn't suddenly transmogrified into
a new box), the hello is ignored.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2012 17:22:09 +0100

> RPC (get-hello?) get the hello contents?

The big hit is the key generation - the <hello> is a piece of cake
compared to that.

> caching keys between connections to reduce the exchange ssh does

You may be interested in this:

http://dx.doi.org/10.1109/INM.2009.5188805

If someone needs access because your company does not have IEEE
eXplore access, contact me privately. I am not sure how to get
something like this into common open source implementations...

/js

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2012 10:58:23 -0500

>http://dx.doi.org/10.1109/INM.2009.5188805

Exactly!

>something like this into common open source implementations...

You send a patch to openssh.com ;^)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 09:02:54 -0800

On 01/19/2012 07:38 AM, Phil Shafer wrote:
> Martin Bjorklund writes:
>> I think Andy refers to the client - to the client,<hello>  is not
>> meaningless.
>

Not all applications are hard-coded to your server data models.
It is quite possible to use the server <hello> to figure out
the exact YANG content and NETCONF capabilities supported.
The <hello> is very important to application developers who
do not want to hard-code everything for a specific version of 1 server
implementations.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2012 18:19:17 +0100 (CET)

> a new box), the hello is ignored.

So it isn't ignored - you do the sanity check.  Expanding a bit on
this, what we do is the first time the OSS system connects it performs
a discovery, checking the protocol capabilities and data models
supported on the device.  The next times it connects, it will do the
sanity check, in order to handle software upgrades etc.

And of course, the new SSH framing scheme in 6242 is dependent on the
hello message.

I can easily imagine another design w/o a big hello message that would
achieve the same goals (minimal hello + mandatory rpc), but I don't
think it is worth the trouble changing it, especially not in NC/light.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2012 12:05:11 -0500

>Not all applications are hard-coded to your server data models.

Clearly, that's neither what I said, nor what I meant.

The OSS system keeps an inventory of all devices, their type/model/os
information, supported data models and capabilities, as well as
ports, installed hardware, etc.

When the OSS user asks to provision a tunnel between two interfaces
on two devices, the OSS system knows (by virtue of that inventory
information) what those devices support.  It generates a configuration
payload that is specific to those devices, both in content and data
model.

When it goes to talk to the device, it's not interested in new
inventory/data model/capability information.  It wants to perform
the RPCs given to it by the upper levels of its OSS brain.  It
might use that data as a sanity check, but the content is already
in the pipeline and it's not going to change during the hello
phase.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2012 12:07:39 -0500

>think it is worth the trouble changing it, especially not in NC/light.

I guess I should go read the draft, since it seems like if we're
not worrying with backward compatibility, then removing the hello
and forcing the new framing protocol would be a great outcome.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2012 18:44:34 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> not worrying with backward compatibility,

Right, this is a new protocol.  Or rather a new version of NETCONF.
Sort of.  It uses the same port, same subsystem, I believe.  Should we
do a NETCONF 2.0 instead with a more modular approach to the
operations?

> then removing the hello

I'm glad we had the hello as it was, b/c otherwise we couldn't have
done the new framing the way we did...  so I think we need some sort
of hello; maybe only advertising the protocol version and some hash or
something of the rest.  If the client's cached hash doesn't match the
server, it can ask for the rest using a new rpc.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Jan 2012 19:02:35 +0100 (CET)

> do a NETCONF 2.0 instead with a more modular approach to the

My own answer to this question: No, we shouldn't ;-)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 10:04:02 -0800

On 01/19/2012 09:44 AM, Martin Bjorklund wrote:
> Phil Shafer<[email-masked]>  wrote:
>> Martin Bjorklund writes:

Back up a second...

I don't agree that constrained devices warrant a special, non-backward-compatible
version of NETCONF.  IMO, a device that can only move its bulk config to
and from the device can just use a file transfer protocol. NETCONF is the wrong
tool for the job.

What about all the NETCONF capabilities like :writable-running, :startup, etc?
Are these hard-wired for all Light implementations as well?

Deviations can be used to let a server advertise any 'less than full' NETCONF,
not just the handful of deviations hard-coded into NETCONF Light YANG features,
and the client can implement this standard mechanism in a uniform way.
(Nothing special about 'not-implemented' for the get/filter parameter vs.
any other RPC input parameter).

The base:1.1 protocol was only published 6 months ago.
I don't think there are enough new problems with the protocol to
work on any new version.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 11:22:52 -0800

> and forcing the new framing protocol would be a great outcome.

Yes -- read the draft.
I just read it carefully, and it is hard to recognize what features of NETCONF
are actually retained in NETCONF Light.

Comments:

  * A server does not have to implement anything, not even <close-session>.
    NMS developers like to code only to mandatory-to-implement server features,
    and there are none in NETCONF Light.
  * There is no mention of all the NETCONF capabilities like :candidate,
    :writable-running, and :startup, which is very important
    to NETCONF clients.  I assume there is just a running config, and if the
    edit-config or copy-config feature is advertised, the client converts that to
    the :writable-running capability.

  * It is not clear whether base:1.0 or base:1.1 protocol operation versions are used.

  * It is not clear if any YANG modules representing content are advertised.
    How does the client know what database contents are supported?

  * It is not clear if any existing capabilities, such as :partial-lock, :notifications,
    :with-defaults, etc., could be supported by the server, or if it is assumed
    this is not supported

  * It is not clear if a server could support custom RPC operations, or how a
    client would know about them.

  * There is no mention of the <validate> operation.  I assume this is because the
    server only has a running config, and that config is always supposed to be valid.

  * If the server only has a running config, then <delete-config> makes no sense.

Editorial:

  * sec. 3.1.1 has a cut-and-paste error about edit-config

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 11:47:28 -0800

> We are compliant with that. ;-)

Why did we put that text in there?
I argued for a more robust conformance model in YANG but lost that debate.
All we have is "implement everything, or here is the list that flags you
as non-compliant to all your competitors and customers".

SMIv2 conformance allows for standard deviations ;-)

>>> is in my view much better than failing unexpectedly. Of course, your
...
> of NETCONF - that has happened before.

If NETCONF Light had a useful set of mandatory-implement functionality,
I could see this approach being worthwhile:

   * A server MUST provide a writable, running configuration datastore
   * A server MUST NOT support the candidate or startup datastores
   * A server MUST advertise any NETCONF capability it supports, such as :xpath or :url
   * A server MUST support the <copy-config>, <get-config> *, and <close-session>
     operations.  (* == <filter> not included in this requirement)
   * A server MUST advertise a YANG module capability for each module it supports
   * If <edit-config> or subtree filtering is supported, the :with-defaults basic-mode
     capability MUST be advertised

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Jan 2012 12:15:57 -0800

> My own answer to this question: No, we shouldn't ;-)

Agreed, as that wouldn't be backwards compatible.  But an observation we had was that this is how NETCONF should've been presented in the first place and that "NETCONF Light", if given wings, has the potential of eclipsing NETCONF over time.  To this end, I suggested renaming it to something that would better allow it serve that purpose it the future - that is, now we see it as a light version of NETCONF, later it might be the primary protocol.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Jan 2012 12:42:52 -0800

> in the pipeline and it's not going to change during the hello

A couple comments on this aspect of the discussion:

1. Our NMS systems are heavily dependent on what devices present in their <hello>.  For instance, if the user right-clicks on a device in the UI, the user-options are directly keyed off of what the device advertised.  For instance, if the device didn't advertize our vendor-specific "license" capability, the option to "View/Manage Licenses" would be grayed-out for that device.  Likewise, if the device doesn't advertize support for configuration (i.e. the :base capability), we disable the ability for the user to View/Manage Configuration.

2. When pushing config to the device, our NMS systems pass down to their lower-layers enough information for them to generate the <edit-config> message to send to the device.  We do this so that the upper-layers don't have to be concerned with various combinations of optional capabilities devices can present - both IETF's (:writable-running, :candidate, :confirmed-commit, etc.) as well as our own (:rename, :ordered-list, :deactivate, :implicit-change, etc.).  It's not the case the that upper-layer constructs the message for the lower-layer to blindly push to the device.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jan 2012 13:02:13 -0800

On 01/19/2012 12:42 PM, Kent Watsen wrote:
>
>
> Phif Shafer writes:
>> When it goes to talk to the device, it's not interested in new inventory/data model/capability information.  It wants to perform the RPCs given to it by the upper levels of its OSS brain.  It
>> might use that data as a sanity check, but the content is already in the pipeline and it's not going to change during the hello phase.
>
>
> 1. Our NMS systems are heavily dependent on what devices present in their<hello>.  For instance, if the user right-clicks on a device in the UI, the user-options are directly keyed off of what the
> device advertised.  For instance, if the device didn't advertize our vendor-specific "license" capability, the option to "View/Manage Licenses" would be grayed-out for that device.  Likewise, if
> the device doesn't advertize support for configuration (i.e. the :base capability), we disable the ability for the user to View/Manage Configuration.
>

Good!
This is an important part of NETCONF.
I like the 'big <hello>'.  Its size scales with the device complexity
so a tiny server will have a tiny <hello> message.

If implemented correctly by the server, then 3rd party applications
have some hope of supporting proprietary servers, even if it is 1 esoteric capability
at a time.  Allowing a client to key off a list of capability URIs is a big advance
over the complete trial-and-error data silo approach of the past.

(This all seems absent from NETCONF Light though.)

> 2. When pushing config to the device, our NMS systems pass down to their lower-layers enough information for them to generate the<edit-config>  message to send to the device.  We do this so that
> the upper-layers don't have to be concerned with various combinations of optional capabilities devices can present - both IETF's (:writable-running, :candidate, :confirmed-commit, etc.) as well as
> our own (:rename, :ordered-list, :deactivate, :implicit-change, etc.).  It's not the case the that upper-layer constructs the message for the lower-layer to blindly push to the device.
>
> Thanks, Kent
>
>
>

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Jan 2012 15:11:33 -0800

>    and there are none in NETCONF Light.

I would think that an NMS coded to support NETCONF Light would support all the operations, if it wishes to be competitive with other NMS offerings.  But this is a decision for the NMS vendor to make, to sink or swim - or maybe the NMS only desires to support the vendor's in-house devices...

>    the :writable-running capability.

Section 3 says:

   A NETCONF Light implementation, like any NETCONF implementation, does
   not have to support any of the optional NETCONF capabilities.  The
   normal NETCONF rules apply for the capability exchange with <hello>
   messages.

A more explicit statement could be useful.

>  * It is not clear whether base:1.0 or base:1.1 protocol operation versions are used.

This may have been left out, but the intent was that NETCONF Light would shadow NETCONF revisions going forward.  This release is the modularization of base/1.1.  If ever there is a base/1.2 or base/2.0, we'd simultaneously release a revision to NETCONF Light to support a modularized version of it.

>    How does the client know what database contents are supported?

They may be (see above)

>    :with-defaults, etc., could be supported by the server, or if it is assumed

They may be (see above)

>    client would know about them.

They may be (see above).  Actually, the first bullet-point in both Section 2.2 and Appendix B directly address this case.

>    server only has a running config, and that config is always supposed to be valid.

All and any standard NETCONF capabilities may be advertized.  The "description" in the YANG module says:

    "Advertizing all NETCONF Light features is equivalent to advertizing the
     NETCONF base capability itself."

>  * If the server only has a running config, then <delete-config> makes no sense.

This is an issue in the NETCONF protocol too, right?

Kent

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2012 20:55:45 -0500

Kent Watsen writes:
>1. Our NMS systems are heavily dependent on what devices present in their <
>hello>.  For instance, if the user right-clicks on a device in the UI, the
>user-options are directly keyed off of what the device advertised....

I make the assumption that when the user right clicks, the information
being used to display the menu comes from local database, not from
the device itself.  You've reaped this data and recorded it locally.

> It's not the case the that upper-layer constructs the message
> for the lower-layer to blindly push to the device.

"upper" and "lower" may be confusing here.  My point is that you
make the configuration before contacting the device.  You use box
data that you've recorded, not live from the device.

The layers are typically:

[ service oriented layer; knows what you are trying to do ]
   |
   v
[ translation/adapter layer; knows how to turn service to device and vice versa]
   |
   v
[ netconf library; knows the netconf protocols]

This allows multiple adapters and multiple protocols, allowing your
app to talk to many types of devices over many mgmt protocols.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Jan 2012 09:15:33 +0100

> are actually retained in NETCONF Light.

Thanks. Perhaps the document can improve.
 
>    and there are none in NETCONF Light.

Correct. Instead of making an arbitrary choice, we left it open,
giving the WG something to discuss. :)

> * It is not clear whether base:1.0 or base:1.1 protocol operation versions are used.

Count the references to RFC 6241 for that matter. I fail to see how
someone can come to the conclusion NETCONF Light is based on RFC 4741.

>    How does the client know what database contents are supported?

No change here. NETCONF Light really only modularizes the number of
operations that must be supported and makes subtree filtering
optional.

>    :with-defaults, etc., could be supported by the server, or if it is assumed

See the document.

>    client would know about them.

No change from NETCONF as defined in RFC6241.

>    server only has a running config, and that config is always supposed to be valid.

Because validate is an optional capability anyway.

>  * If the server only has a running config, then <delete-config> makes no sense.

Yes. The idea is that implementors will implement and advertise
meaningful combinations of operations.

>  * sec. 3.1.1 has a cut-and-paste error about edit-config

Thanks, consider it fixed.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 20 Jan 2012 02:15:47 -0800

On 01/20/2012 12:15 AM, Juergen Schoenwaelder wrote:
>>   * A server does not have to implement anything, not even<close-session>.

The draft talks about tiny constrained devices like the kind CORE WG is addressing,
but it also refers to big routers which just can't be bothered to implement
NETCONF correctly as "constrained devices", and I don't agree with that
part of the charter.

The draft appears to be an server-centric attempt to lower the implementation
bar to zero for servers, which lowers the functionality that an NMS developer
can count on to zero as well.

NMS developers do not like optional features that are only present on
a subset of the devices they need to support. I don't see any reason
for them to be interested in NETCONF Light if it has no guaranteed features.

Andy

>>   * There is no mention of the<validate>  operation.  I assume this is because the
>>   * If the server only has a running config, then<delete-config>  makes no sense.
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Jan 2012 13:06:04 -0800

> app to talk to many types of devices over many mgmt protocols.

Indeed, yes, this is what we do, but this came about because you stated:

  "To most of our clients, the hello is meaningless.  The OSS system above them
   knows what the server device is, has generated configuration for it, and wants
   the client library to commit that code.".  

This isn't our case, our client (the "netconf library" in your stack?) cares about the <hello>.  What the device advertises on each connection to the NMS is used to guide the construction of the <edit-config> message pushed to the device.  If we ever implement support for the system-notification draft, we would additionally key off the "netconf-capability-change" event.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Jan 2012 15:00:27 -0800

> NETCONF correctly as "constrained devices", and I don't agree with that

The draft doesn't say that the devices can't be bothered, but that it's either impossible or because the support must be phased in over time.  Juniper mandates all devices implement NETCONF, there's no question as to if, but when.  This is reality, things like locking are sometimes not possible to implement and, likewise, it takes time to define schema for a data-model and implement convertors to/from a native implementation.

> can count on to zero as well.

It's not an attempt to lower the implementation to zero, it's an attempt to enable servers to advertise the subset they got working.  We much prefer they do this than either falsely claim everything's working or delay claiming they have anything working until everything is working.

> for them to be interested in NETCONF Light if it has no guaranteed features.

As a lead developer for NMS development at my company, I assure you that we are interested in NETCONF Light, as it enables a formal mechanism for a device to advertise the subset it supports.   We don't have the luxury of waiting until a device's NETCONF implementation is 100%, we need NETCONF Light to avoid inconsistency issues (such as from a device blindly returning <ok/> for locking) and provide better user-experience (knowing up-front is better than keying off <rpc-error>)

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 20 Jan 2012 16:39:31 -0800

On 01/20/2012 03:00 PM, Kent Watsen wrote:
> As a lead developer for NMS development at my company, I assure you that we are interested in NETCONF Light, as it enables a formal mechanism for a device to advertise the subset it supports.   We don't have the luxury of waiting until a device's NETCONF implementation is 100%, we need NETCONF Light to avoid inconsistency issues (such as from a device blindly returning<ok/>  for locking) and provide better user-experience (knowing up-front is better than keying off<rpc-error>)
>
>

You could do this today with YANG deviations if you wanted.
Implementation issues like blindly returning <ok> for locking
should be fixed.  At least return operation-not-supported.
Hiding an rpc-error from the user is just an implementation detail.
The difference between printing "operation not supported", before vs. after
an RPC request, is not a compelling reason to start a new version of NETCONF.

I don't think there is enough standards value in this draft
to be worth implementing, but I'll shut up now since others
appear to want to implement it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Jan 2012 09:44:12 -0800

> and forcing the new framing protocol would be a great outcome.

you are sort of raising 2 new issues.

1) <hello>

I like the idea of a 'short' hello and an RPC to get the full hello.
The server would send just the session-id + NETCONF Light capability + a capability
that had an opaque string ID that represented its current set of
capabilities.  (Every sys-capability-change event causes the server
to change this string to a new unused value.)

The client caches the 'capability-id' capability and only needs to
call <get-hello> if the string changed value.

But a full base:1.1 server needs this feature as well.
The bigger the server, the more capability URIs there are.

2) framing

Base:1.1 servers already have the option of rejecting a base:1.0 session
request, and only supporting the new framing.  We MUST keep the old EOM
after the hello hack because the client may not know for sure what version
server is listening on port 830, so the protocol needs to remain the same
wrt/ SSH framing for the <hello> message.

Andy