Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt

From: Andy Bierman <[email-masked]>
Date: Thu, 1 May 2014 08:23:46 -0700

On Wed, Apr 30, 2014 at 9:18 PM, Kent Watsen <[email-masked]> wrote:

>
>
>
> Hi Juergen,
>
>
> > Kent,
> >
> > the process is somewhat like this
> > <snip/>
>
> I can¹t help the timing on this.  The reason this is coming up now is
> because the NETCONF WG wanted to unify the TLS and SSH config, which meant
> that suddenly the TLS config showed up in a the
> draft-ietf-netconf-server-model, which is supposed to be about configuring
> the server (not user auth).  Maybe the issue can be traced to 5539bis-00
> (Sep 2012), as that is where the TLS-auth config was very first
> introduced.  Perhaps it should¹ve been put into the
> draft-ietf-netmod-system-mgmt at that time, but the issue was less visible
> then since it kind of makes sense that the config would be in the 5539bis.
>  In fact, Tom said as much here:
> http://www.ietf.org/mail-archive/web/netconf/current/msg08841.html.
>
>
>
> >Of course, since there is another IETF last call, you can raise an
> >issue during this second IETF last call if you believe the document is
> >not ready.
>
> And that we should do if we agree that it¹s the best course of action.
>
>
>
> ><history deleted>
> >So keep this in mind when you think about the issue. Are we having an
> >issue that renders the current version unusable or is this just one of
> >the many additions one can imagine but which may as well go into a
> >future revision or augmentation of the data model? In the later case,
> >I prefer to not pull this document out of the IESG back into the WG.
>
> The problem is that if it doesn¹t go into draft-ietf-netmod-system-mgmt,
> then the alternative solutions (see bottom) may compound the problem.  Now
> is the time for us to at least look at it and agree what makes sense.  I¹m
> all for us doing the right thing, whatever it might be, but we haven¹t
> even discussed what that is yet.
>
>
>
> >PS: I personally do not believe that the user authentation objects in
> >    the sytem draft need configuration of certifications and trust
> >    anchors.
>
> Great, the discussion begins, so here goes.
>
> The netmod-system-management defines config for User Authentication and
> says that it does so for SSH because that is NETCONF¹s mandatory to
> implement transport.  Meanwhile we have netconf-server-model, which is
> suppose to be just about configuring the NETCONF server, and yet it has
> user-auth config for TLS (not SSH) in it.  This inconsistency is the issue.
>
>
> So, what are our options?
>
> 1. Go forward with current inconsistency
>
> 2. Only modify draft-ietf-netconf-server-model, but move TLS user-auth out
>    of ietf-server-model into a separate model that augments ietf-system
>
> 3. Similar to #2, but move the ietf-system augmentation back to 5539bis
>
> 4. Similar to #2, but move the TLS-auth directly (no augmentation) into
>    the ietf-system model defined in draft-ietf-netmod-system-mgmt
>
> 5. Move all user-auth config from draft-ietf-netmod-system-mgmt into
>    draft-ietf-netconf-server-model
>
> 6. Move all user-auth config from both draft-ietf-netmod-system-mgmt
>    and draft-ietf-netconf-server-model into yet another draft (for
>    instance, draft-ietf-netmod-user-auth?)
>
> 7. Anything else?
>
>
I think (2) is OK.

Thanks for explaining why we need service-level conformance specification
for YANG. YANG modules are just building blocks.  The real high-level API
may be defined in 1 sub-tree, but it will be spread across 10 YANG modules.

We have to be able to deliver YANG modules in RFCs in an unimpeded fashion.
There will always be new stuff the pipeline.  YANG needs to be robust enough
to deal with this reality.

Given the existing YANG conformance limitations, you need to carve up
the new functionality (either w/separate modules of w/ YANG features).
We have to use augment a lot more. We have to maintain data organization
without rewriting or republishing modules constantly.

> Thanks,
> Kent
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 May 2014 14:39:25 +0200

> even discussed what that is yet.

Since there are no concrete edits people agree on at this point in
time, I do not plan to move draft-ietf-netmod-system-mgmt back form
the IESG into the WG to work on it a couple of more weeks and then to
restart the whole procedure.

> user-auth config for TLS (not SSH) in it.  This inconsistency is the issue.

I do not think this is a fair summary. Both, SSH and TLS call home
need parameters configured on the NC server side but also on the NC
client side, (e.g. the SSH user and its credentials to call home).
Where will this stuff go?

Sure, we can move the cert-maps and psk-maps to some other module, I
am not sure though it really helps solving a concrete problem. These
are at the end objects to implement on the NC server, whether they are
defined as part of draft-ietf-netmod-system-mgmt, netconf-server-model
or some other module. And the maps are rather NETCONF over TLS
specific.  The SSH authentication objects may also be used outside
NETCONF, e.g. to configure plain old access to the system's CLI.
 
>    instance, draft-ietf-netmod-user-auth?)

As NETMOD WG co-chair, I want to publish draft-ietf-netmod-system-mgmt.
Building "perfect" modules means we will never finish. Once again,
modules can be revised and augmented if needed.

/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: Fri, 9 May 2014 22:57:25 +0000

Hi Juergen,

>> says that it does so for SSH because that is NETCONF's mandatory to

Are you asking where NC client information is configured? - as in which
yang model it can go into?

We don't define yang models for NC clients, so what do you mean?

FWIW, on the client side, there are two call-home preconditions:

1. The client needs a trust anchor to verify the device with.  This could
be, for instance, a vendor's well-known CA certificate that the NMS
installed a priori.  Or it could be that the NMS has the device's TLS
server-cert or SSH host-key.   Either way, how the NMS obtains this
information is unspecified in both the 5539bis and reverse-ssh drafts.

2. The client needs to know what user credentials to use when logging into
a device.  As always, the device must be configured with a local user
account.  How the NMS knows the account information configured on the
device is also unspecified in both the 5539bis and reverse-ssh drafts.

>modules can be revised and augmented if needed.

So I take it you're ok with options 1, 2, or 3.   Andy said 2 was OK and
no one else responded.   I think that 2 is better than 1 and tied with 3.
So it looks like 2 has the lead, as weak as it is.

Thanks,
Kent