Subject: [Netconf] document status

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 10:01:06 +0200

Hi,

I see that the document is now in the state "Approved-announcement to
be sent::Point Raised - writeup needed". Not sure what the point
raised is but I thought I let you know that I do have a version of the
I-D that incorporates all the edits that were suggested during the
IESG chat preparation phase. I am happy to post that any time in case
this helps. Attached is the rfcdiff.

/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: Joel Jaeggli <[email-masked]>
Date: Fri, 10 Apr 2015 13:15:56 -0700

Looks good, if you post the we'll announce it on the mailing and ship to the EMC editor.

The state was to keep it from being published prior to this.

Thanks
Joel

Sent from my iPhone

> On Apr 10, 2015, at 01:01, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
> 
> <draft-ietf-netconf-rfc5539bis-10-from-09.diff.html>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 23:04:48 +0200

> Looks good, if you post the we'll announce it on the mailing and ship to the EMC editor.

I have posted -10.

/js

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Apr 2015 10:55:24 -0700

>> Looks good, if you post the we'll announce it on the mailing and ship to the EMC editor.

Thanks,

Benoit, when you get back since you still hold the token on this would
you kick it into the rfc editor queue.

joel

---

From: Benoit Claise <[email-masked]>
Date: Sat, 11 Apr 2015 16:14:50 +0200

>> Looks good, if you post the we'll announce it on the mailing and ship to the EMC editor.
Let me follow up from here.
I'll double-check everything (probably on Monday) and move it to the 
RFC-editor queue.

Regards, Benoit

---

From: t.petch <[email-masked]>
Date: Thu, 16 Apr 2015 09:09:46 +0100

Juergen

Too late for this I-D but picking up on Kathleen's comments, I suggest
an informative paragraph to the NETCONF I-Ds explaining the various
documents and their roles.  You don't need it, I don't, at present, but
if the likes of Kathleen do, then I think that we should provide it.
Something like,

NETCONF requires a secure transport with mutual authentication.
Originally, three were specified, SSH, SOAP and BEEP.  Later, TLS was
added while SOAP and BEEP are now of Historic status.  The WG also took
on
the work of RESTCONF, 'netconf-restconf', a  NETCONF-like protocol over
HTTP.  Along the way, TLS as a transport for NETCONF gained and lost
means of authentication other than X.509 certificates, while SSH added
authentication using X.509 certificates to the more common use of host
keys.

The specification of SSH as a transport was revised in 2011, that for
TLS in 2015, notably to change the method of delineating messages.

A requirement arose for the NETCONF server to initiate the TCP
connection, to be the TCP client, after which it would still become the
NETCONF, and SSH or TLS, server.  Initially referred to as
'reverse-ssh', this is now known as 'call home' and the document,
'netconf-call-home', covers both TLS and SSH, NETCONF and RESTCONF.

'netconf-server-model' defines a YANG model for the configuration of a
server, again both for NETCONF and RESTCONF, and for TLS and SSH.

Finally, 'netconf-zero-touch' builds on this to facilitate the initial
configuration of a remote device.

(with references as appropriate)

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2015 10:47:41 +0200

I might agree that we need _at some point in time_ an overview like
_document_, something similar to RFC 3410. Given where we are, I think
it is too early to write this and we also have higher priority things
to _finish_. (As Andy said, starting things is easy, finishing things
is hard.) I think I disagree that we should add the history of how
things evolved to all NETCONF I-Ds.

Until we have the cycles and the document stability to write something
equivalent to RFC 3410, perhaps some text on the NETCONF wiki would
work as well.

/js