Minutes for NETCONF at interim-2014-netconf-4
minutes-interim-2014-netconf-4-2

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.