Subject: [Netconf] Draft minutes from the NETCONF Virtual Meeting on Monday, October 20, 2014 1800 UTC

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 23 Oct 2014 18:00:43 +0000

Dear NETCONF WG,

below are the minutes from the NETCONF virtual meeting on Monday, October 20, 2014.
As for all physical and virtual WG meetings the issue discussion needs to be verified on the maillist.

All: Please provide your comments and feedback to the maillist concerning the conclusions from the virtual meeting.
If there is no objection to the conclusions, the draft authors are going to act as discussed.

Additional information on the issue discussion is available on netconf-wg github:
https://github.com/netconf-wg/restconf/issues and
https://github.com/netconf-wg/server-model/issues
https://github.com/netconf-wg/call-home/issues

If there are no change requests from the attendees, the minutes below will be sent to [email-masked]<mailto:[email-masked]> tomorrow EOB (please send your request to the co-chairs).

PS: Please be aware that the virtual meeting on November 3, 2014 has been canceled by the organizers.

Regards,
Mehmet

Minutes of the NETCONF Virtual Meeting on October 20, 2014

Attendees:

JS = Juergen Schoenwaelder

MB = Martin Bjorklund

AB = Andy Bierman

ME = Mehmet Ersue

MJ = Mahesh Jethanandani

LL = Lada Lhotka

AL = Alan Luchuk

JT = JF Tremblay

KW = Kent Watsen

AI = Action Item

Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC

-----------------------------------------------------------------------

- 5 min chair intro - recording the meeting?, scribe, agenda bashing

The tool Etherpad has been used for notetaking.

- 10 min rfc5539bis and X.509 certificate authentication (Juergen)

JS: certificate based auth is already there.

We should remain consistent with the usage in SNMP.

AI: JS to ask Tom Petch what he is missing.

MB: Consistent set of document is probably what Tom is missing.

Server model can be updated to state that these are now consistent.

KW: 5539bis should be self-standing without normative reference to

server model draft.

AI: Mehmet will ask Kent to update.

- 45 min restconf open issues (Andy)

   See https://github.com/netconf-wg/restconf/issues

   RESTCONF #3: add collection resource

   https://github.com/netconf-wg/restconf/issues/3

   http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html

Conclusion in Github:

The original plan to add a basic collection resource will be

done in the next release (if possible). Only basic pagination

(offset + limit) will be supported. Future work may extend the basic

features.

AI: Martin will attempt to add a basic collection resource in time for

IETF #91

   RESTCONF #12:   target resource list or leaf-list keys required for GET

   https://github.com/netconf-wg/restconf/issues/12

   Not on the tracker yet:

   - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RFC?

   JS: One way of discovering models for Restconf and Netconf.

   Where this is defined is 2nd prio

   - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for release 1?

 MB: Why don't we introduce an ID for Restconf?

Will there be different streams for rest- and netconf?

It'll be the same stream.

 AB: We need an agreement on what it means they are colocated.

 One more issue concerning add collection resource

To be returned (currently) when doing a GET on a URL that points to

the list, w/o any keys. Should support offset / limit query parameters.

LL: invalidity of the reply any concern for JSON.

Conclusion in Github:

This issue is related to #13, which has been opened now.

The basic collection resource support should resolve this issue

Conclusion for issue #13:

The ietf-yang-library contains YANG module information that may

be applicable to NETCONF or other protocols that use YANG modules.

Should this module be in a separate RFC?

Current consensus is no, leave it in RESTCONF RFC.

- 35 min netconf-server model open issues  (Kent)

   see: https://github.com/netconf-wg/server-model/issues

   Issue #4: How to configure NETCONF server's SSH host-keys or TLS certificates

Conclusion in Github:

There was consensus for the proposal to add top-level "netconf-server/ssh"

and "netconf-server/tls" containers to, in part, list out the (config

false) system's SSH host-keys and TLS certificates. This so that these

keys can then be referenced by both the listen and call-home configurations.

Additionally, Kent explained that configuring said keys has turned out

to be more difficult than first thought, due to the wide array of algorithms

and key-generation/signing strategies involved. Perhaps RFC 7210 (mentioned

by Mahesh above) should be looked at.

   Issue #8: what other server config knobs are needed?

Conlusion:

AI for MB to provide parameters their server supports.

Then KW will try to find the common parameters between the three servers.

   Issue #13: enable indirect Issuer authentications?

Conclusion:

There was general consensus that this was the way to go.

AI: Take to the maillist.

   Issue #15: Should the "listen" and "call-home" lists have parent containers?

Turns out that there is no best-practice around use of parent containers

for lists. There wasn't even consensus that a single module need be

self-consistent. In the end, it was decided that it was purely a modeler's

discretion and that this is essentially a non-issue.

AI: Take to the maillist.

- 20 min netconf-call-home open issues  (Kent)

  https://github.com/netconf-wg/call-home/issues

   Issue #3: Extend to support RESTCONF as well?

KW explained that the config model for NETCONF call-home using TLS was

essentially identical to what would be needed for RESTCONF call-home using

TLS (HTTPS). And further that the concern for HTTP sessions was unwarranted

if RESTCONF requires HTTP/1.1 (which defaults to persistent connections)

and recommends setting http server timeouts to something reasonable like

5 minutes.

MB questioned if the need for call-home existed. That is, if RESTCONF is

used primarily for off-box applications/controllers - do they need to

call home too? Kent agreed that applications/controllers would likely not

need to call-home, but that we should't dismiss RESTCONF being deployed

instead of NETCONF on a NE, in which case RESTCONF call home would be

important. The discussion went further into why RESTCONF wasn't deemed

suitable for production, to which it landed on not having a confirmed-commit

equivalent. Martin said that he tried once, but couldn't find a simple

solution. Kent and Martin to sync up offline.

Conclusion:

MB and KW agreed that, if we do support RESTCONF call-home (or even not),

it would be best for draft-ietf-netconf-server-model to have another

top-level module (e.g., ietf-restconf-server) that shared groupings with

the existing ietf-netconf-server module.

   Issue #4:  Have a call-home port?

KW explained that with RESTCONF call home, the number of ports requested

from IANA would then be three, which ratchets up the potential need to

define a single port. And that since now we have a single call-home draft

for all transports, it would be much simpler to do than before.

AI: KW to provide a proposal and ask the maillist for feedback.

- 5 min AOB other topics

The next virtual interim meeting on November 3, 2014 just before IETF #91

meeting has been canceled.