Subject: Re: [Netconf] keystore and the client/server drafts

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Jun 2017 16:31:43 +0000

Also, please note that I made a couple decisions in these updates that 
should highlighted, in case folks want to discuss them more:

1) Balazs suggests adding a feature statement on the 'trusted-server-certs'
   container in the ietf-tls-server and ietf-ssh-server modules.  The last
   comment here was/is: "it really depends on your strategy when deciding
   between features versus deviations".  My view is that a deviation here
   makes more sense, hence why the current modules don't add any additional
   feature statements.

2) Juergen suggests the ietf-netconf-client and ietf-restconf-client
   modules have both groupings and containers (the latest update
   only has groupings).  While it may be possible for a NC/RC client
   to not need any configuration above and beyond what's provided in
   these groupings, this seems like a corner case not worth supporting,
   and hence why the current modules don't have any containers.

Kent

--

Dear WG,

These latest updates reflect all comments received and close all of 
the open issues.  At this point, there are no more issues to resolve.
I believe that these drafts are now ready for Last Call.

  https://tools.ietf.org/html/draft-ietf-netconf-keystore-02
  https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-03
  https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-03
  https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-03
  https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-03

Thanks,
Kent

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jun 2017 19:48:40 +0200

>    and hence why the current modules don't have any containers.

a) LMAP has a need for this since LMAP has RC clients that invoke an
   RPCs on a server and it is necessary to provide them with the
   necessary credentials etc. Perhaps this is what you call a corner
   case, but it is then at least an IETF WG corner case.

b) Other configuration parameters can be (and typically are) in other
   modules.

c) The argument we don't add a container since there is no container
   is circular or at least not helpful.

/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: Kent Watsen <[email-masked]>
Date: Thu, 15 Jun 2017 11:02:06 +0000

Hi Juergen,

I don't know much about LMAP.  Is it expected that the entire physical
or virtual appliance is a single RESTCONF client, or is the RC client
more like a part of a larger system?  How many such clients might there
be?  How are they configured?  Do they have any configuration above
and beyond just the RC client configuration?

Kent

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Jun 2017 13:31:52 +0200

> and beyond just the RC client configuration?

An LMAP measurement agent has two interfaces. The first interface is
towards a controller, the entity in charge of configuring measurement
schedules etc. The second interface is towards a collector, an entity
in charge of collection measurement results. The LMAP measurement
agent acts as a RESTCONF server towards the controller (using call
home where necessary) and it acts as a RESTCONF client towards the
collector. What LMAP was hoping to get out of NETCONF (in addition to
call home) is a way for the controller to configure on the LMAP
measurement agent the parameters needed for the RESTCONF client to
deliver measurement results to a collector.

In other words, an LMAP agent acts as a RESTCONF server to its
controller and as a RESTCONF client to its collectors.

I do not get why it is relevant how much additional configuration
there is or how many LMAP measurement agents there are etc. LMAP
simply has a need to configure the parameters for a RESTCONF client
and we were hoping that NETCONF provides this as an implementable
module.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Jun 2017 15:38:31 +0000

> and we were hoping that NETCONF provides this as an implementable

Sure, but would it make any sense to configure an LMAP server using
a global ietf-restconf-client model, or would you want something 
more like ietf-lmap-server, that 'uses' ietf-restconf-client?

That said, it occurs to me that the ietf-xxxconf-server models, which
currently only define containers, should also define groupings, as
there may be a ietf-foobar-whatever that can configure more than one
ietf-xxxconf-servers - e.g., in different parts of its config tree,
as one might be used for reason-X and the other used for reason-Y.
What do you think?

Of course, if we do this, then you can say that ietf-xxxconf-client
models should also present both groupings and containers, just to be 
consistent...

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Jun 2017 18:17:09 +0200

> more like ietf-lmap-server, that 'uses' ietf-restconf-client?

Interoperability means the same objects in the same namespace at the
same location. I do not get why you think this is a problem.

> as one might be used for reason-X and the other used for reason-Y.

So should we define interfaces groupings so that everybody can
instantiate them where he sees fit? I fail to see the logic.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Jun 2017 09:44:39 -0700

> same location. I do not get why you think this is a problem.
Right -- we had the same issue with SNMP and TEXTUAL-CONVENTIONS.
There is no way to measure the interoperability of a grouping or typedef.
We have published groupings only before for RESTCONF, for use with
the yang-data extension.

We should not publish TBD-management-objects in the form of groupings.
There should be at least 1 "uses" for each published grouping (intended as
management data).

> instantiate them where he sees fit? I fail to see the logic.

The routing modules use a lot of groupings, anticipating a lot of reuse.
But you are right -- we could go overboard future-proofing data structures.
I don't really like choice-stmts with 0 or 1 case-stmt (for example).
There are lots of ways we can make the modules too complicated.

> /js

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 20 Jun 2017 20:53:09 +0000

Hi Juergen, Andy,

Interoperability means the same objects in the same namespace at the
same location. I do not get why you think this is a problem.
<KENT> can you answer the question?   It doesn't make sense because you want
LMAP-server "is-a" or "has-a" RESTCONF-client.  Not, there is a LMAP-server
and, separately, there is a "RESTCONF-client" (whatever that means) that may
or may not be related.

We should not publish TBD-management-objects in the form of groupings.
There should be at least 1 "uses" for each published grouping (intended as management data).

<KENT> this doesn't always make sense.   e.g., the ietf-[ssh/tls]-[client/server]
modules defy having protocol accessible nodes.   e.g., the "tls-client" *grouping*
might be used by a specific apps (e.g., `curl` and `wget`), but each of those apps
would each have their own place for configuring the TLS-layer; it would not be
a global configuration that applies to all TLS-based apps on the box.

<KENT> Interfaces are a global thing, but there can be many different
SSH-based or TLS-based apps on a box.   Similarly, there can be many
different NETCONF-based or RESTCONF-based apps on a box.

<KENT> true, there are a couple instances of the single-option choice
statements in these models, for future-proofing.   Though now I'm not
100% it's still future-proofed, since Balazs added those 'must' statements,
which cannot be changed via YANG update rules...

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Jun 2017 21:04:30 +0000

It seems that this thread petered-out.   I'm hoping that my reasoning below was so compelling that it warrants no response.   At least, that is my going assumption for now, as I prepare to submit updated *-client/server drafts to address Balazs's last comments.   Even if the WG wants to discuss this more, it seems that it could be discussed as part of the Last Call too.

Kent

On 6/20/17, 4:53 PM, "Netconf on behalf of Kent Watsen" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Juergen, Andy,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Jun 2017 23:13:53 +0200

I am not entirely convinced by your reasoning. Do I really have to
write another normative YANG module to instantiate the RC client
grouping for LMAP?  What if I run two LMAP instances on a box - I
write another YANG module?

It is likely rare that someone runs two RC servers on a box (other
than testing and demonstration scenarioes) but if I want to I need to
write another YANG module?

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Jun 2017 21:46:34 +0000

Hi Juergen,

For RC servers, the ietf-restconf-server module has a container, 
and that container supports listening on multiple ports.  So it
would be possible to configure two apps running on the same 
machine, each listening on a different port.

That said, I've always been okay having the container in the RC and
NC server models.  It's having containers in the RC and NC *client*
models that I can't make sense of...

FWIW, above I mention that ietf-restconf-server has a container, 
but be aware that it does not have a grouping (which would be used
by the container) that could be used by other models.  I think it
might make sense to do this, to maximize flexibility.  At least, 
using groupings seems easier than schema-mount, which could be a
fallback option.  What do you think?

Kent

--

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Jun 2017 07:04:36 +0200

> machine, each listening on a different port.

Two listening ports are not the same as two different servers.

> fallback option.  What do you think?

This is now a different topic. I am not sure groupings generally
replace schema-mount.

/js