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

[Andy Bierman <[e-mail]>]

On Wed, Apr 30, 2014 at 9:18 PM, Kent Watsen <[e-mail]> 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