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

From: t.petch <[email-masked]>
Date: Mon, 2 May 2016 10:10:08 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 29, 2016 7:57 PM

>
> 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

As a reason, I think that that is abysmal.

RFC should be aimed at a target audience and, for technology, the
primary audience is those who will implement it (often a rather small
number) closely followed by those who use it and need to understand how
it works in detail (a rather larger number).

You are saying that it should be written for its aesthetic appeal to
standards writers; standards writers should swallow their feelings and
lump it - their job is to satisfy implementers and users (as above).

As Andy said, three seems the obvious number (unless that leads to a
complex mesh of dependencies which, as I alluded to before, makes things
hard to understand; currently, I do not think that that is the case).

Tom Petch

> 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]:[email-masked]
>
> On Fri, Apr 29, 2016 at 8:49 AM, Kent Watsen
<[email-masked]<mailto:[email-masked]>> wrote:
>
> 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:
>
> There is currently 1 draft (draft-ietf-netconf-server-model-09)
correct?
>
>     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
>
> 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: Mahesh Jethanandani <[email-masked]>
Date: Tue, 3 May 2016 16:18:54 -0700

It appears that a virtual interim meeting might help this discussion and the discussion around key-chain models. 

Consider this a two week notice for the meeting. Details will be sent out later.

Mahesh & Mehmet

> On May 2, 2016, at 2:10 AM, t.petch <[email-masked]> wrote:
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 May 2016 17:12:58 +0000

>Consider this a two week notice for the meeting. Details will be sent out later.

Okay, we had the interim.  The slides I presented then are attached.

Of the various proposals listed in the slides, the interim’s consensus was to move forward with either proposal #2 or proposal #3 (slides 8 and 9).  The only difference between these proposals is that #3 splits out the restconf client/server models into its own draft, as opposed to having them in the same draft with the netconf client/server models.

Assuming the interim’s consensus is upheld here on list, we now need to pick between proposals #2 and #3.   FWIW, I have a slight preference for #3 only because I like the consistency of it.  Any other opinions?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 May 2016 10:29:05 -0700

Hi,

#3 is better to decouple the normative references and instability as each
protocol changes over time.

Andy

On Fri, May 27, 2016 at 10:12 AM, Kent Watsen <[email-masked]> wrote:

> Of the various proposals listed in the slides, the interim’s consensus was
> to move forward with either proposal #2 or proposal #3 (slides 8 and 9).
> The only difference between these proposals is that #3 splits out the
> restconf client/server models into its own draft, as opposed to having them
> in the same draft with the netconf client/server models.
>
> Assuming the interim’s consensus is upheld here on list, we now need to
> pick between proposals #2 and #3.   FWIW, I have a slight preference for #3
> only because I like the consistency of it.  Any other opinions?
>
> Thanks,
> Kent
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 29 May 2016 11:07:19 +0200

> protocol changes over time.

Yes, this is why I also favored #3 during the call. If we go with #2,
I am reasonably sure we will end up with #3 over time when protocol
updates are being made.

/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: Mon, 30 May 2016 10:17:30 +0200 (CEST)

> I am reasonably sure we will end up with #3 over time when protocol

I'm fine with #3.  #2 is also ok.  The most important part is to have
the correct *modules*.  Which document they go into is imo less
important.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Jun 2016 00:38:02 +0000

Thank you everyone that responded.  It appears that the on-list consensus is to go with Proposal #3, a total of 5 drafts (see below).   If no objections are raised before next Monday, I’ll assume that this consensus is confirmed and will start making the changes.

Here is the 5 drafts and their modules from Proposal #3:

1.    draft-ietf-netconf-system-keychain
            - ietf-system-keychain

2.    draft-ietf-netconf-ssh-client-server
            - ietf-ssh-client  
            - ietf-ssh-server

3.    draft-ietf-netconf-tls-client-server
            - ietf-tls-client  
            - ietf-tls-server  

4.    draft-ietf-netconf-netconf-client-server
            - ietf-netconf-client  
            - ietf-netconf-server  

5.    draft-ietf-netconf-restconf-client-server
            - ietf-restconf-client  
            - ietf-restconf-server  

Thanks,
Kent