Subject: [Netconf] Confirming the decision to split the server-model draft into several drafts.

From: Kent Watsen <[email-masked]>
Date: Thu, 28 Apr 2016 23:26:25 +0000

We discussed splitting the server-model draft into several drafts at the IETF 95 in in Bueno Aires.  At that meeting, there was overwhelming support to adopt "Proposal #2" as follows:

    draft-ietf-netconf-system-keychain
    draft-ietf-netconf-ssh-client-server
    draft-ietf-netconf-tls-client-server
    draft-ietf-restconf-tls-client-server

This email is to confirm that decision here on the mailing list.   If this decision is confirmed, we will remove the current draft as a WG item, and add the four drafts listed above - a total of +3 new WG drafts.   Please voice any concerns or objections before Wednesday May 11th.

For completeness, all the proposals discussed at the meeting follow:

Proposal #0:
    Do nothing

Proposal #1:
    draft-ietf-netconf-system-keychain
    draft-ietf-netconf-ssh-client
    draft-ietf-netconf-ssh-server
    draft-ietf-netconf-tls-client
    draft-ietf-netconf-tls-server
    draft-ietf-restconf-tls-client
    draft-ietf-restconf-tls-server

Proposal #2:
    draft-ietf-netconf-system-keychain
    draft-ietf-netconf-ssh-client-server
    draft-ietf-netconf-tls-client-server
    draft-ietf-restconf-tls-client-server

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Apr 2016 10:02:26 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 
> We discussed splitting the server-model draft into several drafts at
> the IETF 95 in in Bueno Aires.  At that meeting, there was
> overwhelming support to adopt "Proposal #2" as follows:
> 

It is not entirely clear which modules would go into which drafts.

I think the functionality we define is:

  o  generic system keychain 
  o  generic ssh client (grouping)
  o  generic ssh server (grouping)
  o  generic tls client (grouping)
  o  generic tls server (grouping)
  o  netconf server model (using the generic modules above)
  o  restconf server model (using the generic modules above)

In terms of YANG modules it makes sense to have:

  ietf-system-keychain
  ietf-ssh-client-server
  ietf-tls-client-server
  ietf-netconf-server
  ietf-restconf-server

I can think of several reasonable ways to combine these into
documents.  The simplest might be:

  o  document for ietf-system-keychain
  o  document for ietf-ssh-client-server + ietf-tls-client-server
  o  document for ietf-netconf-server + ietf-restconf-server

... or one document per module, or somewhere inbetween.

/martin

> 
> This email is to confirm that decision here on the mailing list.  If
> this decision is confirmed, we will remove the current draft as a WG
> item, and add the four drafts listed above - a total of +3 new WG
> drafts.  Please voice any concerns or objections before Wednesday May
> 11th.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 10:15:31 +0200

Do we have a clear understanding what the problem is we are trying to
solve with splitting things into several small pieces?

/js

On Fri, Apr 29, 2016 at 10:02:26AM +0200, Martin Bjorklund wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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: Fri, 29 Apr 2016 10:21:16 +0200 (CEST)

> solve with splitting things into several small pieces?

Are you talking about the YANG modules or documents?

I think it makese sense to split the modules so that generic stuff
that we believe is usable for many other technologies are in separate
modules than the specific netconf/restconf server models.

As for the number of documents, it is probably more subjective; it is
easier to grasp a smaller document that focues on one thing.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Apr 2016 11:25:16 +0200

> modules than the specific netconf/restconf server models.

Yes, modularity is generally a good idea.
 
> easier to grasp a smaller document that focues on one thing.

Yes, but there is also overhead in maintaining consistency across
douments, there is overhead in the IETF processes, and for the reader
in having to assemble bits and pieces from multiple documents mentally
back together.

I guess I should listen to the IETF recordings to understand what has
been driving this discussion so I am better informed.

/js

---

From: t.petch <[email-masked]>
Date: Fri, 29 Apr 2016 12:11:01 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 29, 2016 9:21 AM
> easier to grasp a smaller document that focues on one thing.

Depends.  I think that the principles are easy, their application less
so.

I think it no coincidence how many things are hierarchical - YANG, SMI,
... - it makes them easier to understand; whereas meshes are more
difficult, and I mean meshes in a very general sense, not just in terms
of YANG statements that reference other parts of a module or other
modules.  If I come to a section that gives the details of how to derive
a user name from a certificate, which is self-contained, I can skip over
it and drill down into the detail when I need to later; but if the
section is conditional on the context, SSH, TLS, HTTP, RESTCONF etc or
other parts are themselves conditional on the parts of such
authentication, and I have to disentangle the cases, with references to
other material, then that is complex.

And it depends on the reader.  If they are implementing only RESTCONF
with no call home, then they want a document with only RESTCONF, and do
not want to have to visit other documents to understand other aspects of
authentication or access control or  ... whereas if they are looking at
the security, then they want all the authentication, and may be access
control, together, regardless of whether it is certificate, host key,
PAKE etc.

I think that the coverage of key-chain in the current I-D illustrates
the problem.   It comes first, but do I have to understand its17 pages
in order to understand an SSH server, or can I leave it as a
self-contained high-level function to come back to later?  If the
latter, then move it to a separate I-D, if not, then do not, but from
this I-D, as it stands, I cannot tell.
(draft-ietf-rtgwg-yang-key-chain-02.txt is better in this regard but
still tends to be written for key-chain experts rather then being
something whose interest to me I can judge from Abstract and
Introduction).

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Fri, 29 Apr 2016 15:49:30 +0000

To answer so of the questions posted here:

The motivation is to have well-defined RFCs that make good referenceable targets for future work.  In particular, there may be other transports besides SSH and TLS, or there may be other high-level protocols that use these two transports.

Regarding the intention of which modules would be in which drafts, I just realized that a made a mistake before, also in the slides presented in BA.  Below is correct, there's actually five drafts (not four) having the following YANG modules:

    draft-ietf-netconf-system-keychain
        - ietf-system-keychain  // this we have already today

    draft-ietf-netconf-ssh-client-server
        - ietf-ssh-client  // this would be added
        - ietf-ssh-server  // this we have already today

    draft-ietf-netconf-tls-client-server
        - ietf-tls-client  // this would be added
        - ietf-tls-server  // this we have already today

    draft-ietf-netconf-netconf-client-server

        - ietf-netconf-client  // this would be added
        - ietf-netconf-server  // this we have already today

    draft-ietf-netconf-restconf-client-server
        - ietf-restconf-client  // this would be added
        - ietf-restconf-server  // this we have already today

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Apr 2016 10:07:51 -0700

On Fri, Apr 29, 2016 at 8:49 AM, Kent Watsen <[email-masked]> wrote:

> The motivation is to have well-defined RFCs that make good referenceable
> targets for future work.  In particular, there may be other transports
> besides SSH and TLS, or there may be other high-level protocols that use
> these two transports.
>
> Regarding the intention of which modules would be in which drafts, I just
> realized that a made a mistake before, also in the slides presented in BA.
> Below is correct, there's actually five drafts (not four) having the
> following YANG modules:
>
>
There is currently 1 draft (draft-ietf-netconf-server-model-09) correct?

>         - ietf-restconf-server  // this we have already today

Looking over the current draft, it seems like 3 RFCs would be more
intuitive:

   - keychain
   - NETCONF server
   - RESTCONF server

IMO lumping TLS and SSH together does not imply that the RFC needs
to be updated later to add new transports.  They can be added as needed
via augments.

The 5 module split is not easy to follow.  It is not easy to
see how the modules relate to each other.  Going to a 9 module
split spread over 5 RFCs would probably be impossible to read.

I am not sure what is in each of the "client" modules.
IMO we should have a virtual interim on server-model-09,
before you start refactoring.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 29 Apr 2016 18:57:22 +0000

I'm open to an interim to discuss, if that is what the WG would like to do.

But quickly, the motivating reason for the middle-two drafts (and the modules they define) to be separated is so that configuration models for other (besides NC/RC) ssh/tls-based client/servers (e.g., syslog, smtp, http) could use the ietf-[ssh|tls]-[client|server] groupings without having to have a normative reference to an RFC who's title ostensibly regards NC/RC.

Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 29, 2016 at 1:07 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts.

On Fri, Apr 29, 2016 at 8:49 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Looking over the current draft, it seems like 3 RFCs would be more intuitive:

   - keychain
   - NETCONF server
   - RESTCONF server

Andy

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