Minutes for NETCONF at IETF-90
minutes-90-netconf-1

Notes of the NETCONF session at IETF #90

Agenda, Note well, status of chartered WG items
See http://www.ietf.org/proceedings/90/slides/slides-90-netconf-9.pdf

Reverse Secure Shell (Reverse SSH) - K. Watsen (15 min.)
http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh
http://www.ietf.org/proceedings/90/slides/slides-90-netconf-0.pptx
- three drafts with changes since IETF89 – 04, 05, 06

slide 6:
Juergen Schoenwaelder (JS) – how does the identity thing work and interoperate?
Kent Watsen (KW): The draft doesn't req X.509, if you use it, you will be able
to extract that info from it, will clarify text

Discussion on asymmetric document structure:
Bert Wijnen (BW, as contributor): would that mean that 6242 does not change? No.
5539 will still to be updated for call home, but easier adaptation
Humm: strong hum in favor, none against or abstain. WG members agree with the
proposal to have a single call-home draft.

NETCONF Over TLS update - RFC 5539bis - J. Schoenwaelder (10 min.)
http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis
http://www.ietf.org/proceedings/90/slides/slides-90-netconf-10.pdf
- implementation led to a number of issues – proposed resolutions accepted with
exceptions slide 5 client side configuration of call-home – unclear consensus -
What to do? KW:  we don't define models for clients, so my answer is no. Andy
Bierman (AB): Big change because clients would be required to  be servers as
well, needs clients config => NO

3. NETCONF Server Configuration Model - K. Watsen (15 min.)
http://tools.ietf.org/html/draft-ietf-netconf-server
http://www.ietf.org/proceedings/90/slides/slides-90-netconf-2.pptx
open issues (slide 8)
Issue 1: replace with single list, Martin Björklund (MB) agrees
Issue 2: remove key – keep the recommendation – JS suggest to have a different
key, cannot have ‘no key’. JS: You can't have no key. Balasz Lengyel (BL): with
address problems with multiple servers, agree with proposed solution Issue 3:
replace w/application – no comments Issue 4: use fingerprint instead? Or use
instance-identifier? Or embed in config capabilities (in Netconf server model)
Issue 5: add ability to config host key? JS: The hostkey is sensitive, has to
be protected. We shouldn't replicate the key, should use hash instead of key
replicas. SSH properties should be configured in SSH model. KW: But in call
home you launch new SSH process.  Action item – Kent will bring #4 and #5 to
the list JS: This is only one implementation option. BW: Action on Kent, go to
mailing list. Issue 6: how to configure keep-alive? MB: done by NMS, still
needed? MB: You said keep alives should be initiated by the one who started
connection, so it's not needed in call home. KW: because of symmetry. Agree,
it's not important. BL: many times no notification server, how are they sent?
How does the server do keepalives? KW: This is done in-band, doesn't need
notifications. KW: Tom isn't here, let's take it to list. AB: What does Tom
say? KW: That we should do both. Issue 7: JS: will also be valid for RESTCONF?
Will make the change MB: Wouldn't this config be useful for RESTCONF? If so, it
should be in system. KW: This raises another issue - call home in RESTCONF?

RESTCONF Protocol - A. Bierman (15 min.)
http://tools.ietf.org/html/draft-ietf-netconf-restconf
seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-3.pdf
Open issues:
Issue 1: Select parameter – mandatory to implement?
MB: if optional how would the client know it’s implemented? Mailing list
slide 4
KW: People perceive RESTCONF as Lite, basically everything should be optional.
AB: In CoAP environment this is necessary, we need levels of capabilities.
MB: If it's optional, how would the client know?
AB: I will talk about capabability advertisements. We have to have some way.
BM: select is just hint, the server may send more.
AB: I will take it to the mailing list.
Issue 2: Netconf-state monitoring support – all implementation ignore what the
RFC says – ‘managed by the NETCONF’ meant to support all protocols, not only
NETCONF – all sessions managed by RESTCONF can be in this table. slide 6 MB:
likes the idea, but do we need 6022bis? Can do errata – AB: to send errata text
to mail list. AB: We can (mis)use the unclear text - NETCONF server is not  the
same as NETCONF session. JS: What's the proposal? MB: We should re-use the leaf
identifying the protocol. BW: Proposal has to be clarified.

Issue 3: Secure transport – leave for later
Issue 4: slide 8
KW: Should syntax for key values be changed? Use brackets as in XPath.
AB: This consumes in one character in the URL, not two.
JS: XPath expressions don't work in URLs because of the restricted character
set. slide 9
 KW: Should be optional.
Ladislav Lhotka: Do all RESTCONF messages actually satisfy that I-JSON
restriction that their contents must be JSON object or array? AB: They are
always objects.

Get-bulk query parameter – mandatory or optional? Lada – object or array sent?
AB: object. KW: should be optional. -> to the maillist.
Issue 5: Defaults-handling –
JS: was defaults mandated? Confused?
MB: useful for the client to know the defaults. Resolution – optional
slide 10
JS: At some time RESTCONF was mandating specific handling of defaults.
AB: We have the issue in NETCONF as well, we force the server to add nodes that
are not not there. MB: It's useful for the client to know what the server
supports. It should be optional. Issue 6: Protocol capability URIs? – yes slide
11 Consensus: advertisement of capabilities is needed. Issue 7: Target resource
list keys required for GET – yes – change text slide 12 Resolution: allow GET
to obtain all instances.

YANG Patch Media Type - A. Bierman (10 min.)
http://tools.ietf.org/html/draft-ietf-netconf-yang-patch
seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-4.pdf
slide 4
Should YANG Patch be mandatory? – wat to go – do not make mandatory, add text
with what will go wrong if not done. Lada – optional because of constrained
environments Lada Lhotka (LL): YANG Patch should be optional because
constrained platforms may not need its power - JSON Patch can suffice.

Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen (20 min.)
http://tools.ietf.org/html/draft-ietf-netconf-zerotouch
seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-5.pptx
slide 11
AB: This creates a top-level mandatory node, it should be presence container.
KW: This is the *configlet*, not configuration.

Non-Chartered items:
I2RS Requirements on NETCONF - Jeff Haas (10min.)
See http://www.ietf.org/proceedings/90/slides/slides-90-netconf-8.pptx
slide 1
AB: – what do you mean by full commit? When is the enforcement done?
Jeff Haas (JH): full validation; AB: – done every edit? Jeff: yes;  JH: Every
edit. AB: – very slow. Jeff – not require many changes MB: What does EE mean?
JH: Atomicity is required. MB: You probably don't need anything from NETCONF.
The "full commit" has no meaning for state data. Bert – Dean Bogdanovi?
(jabber) prefers RESTCONF rather than NETCONF with I2RS, which is per device
BL: Do you mean a real datastore? Or just patches? JH: Open question. BL: if
patches, new concept Mehmet Ersue(ME): What can we do for ensuring effective
exchange of information between I2RS and NETCONF WG? Jeff – can write I-D, one
I-D for reqs from NETMOD, NETCONF in different chapters ME: One I-D would be
sufficient. JS: – timing? Jeff – before next IETF, maybe in a couple of weeks,
as data store defined

A NETCONF Extension for Data Fragmentation - G. Zheng (10 min.)
http://tools.ietf.org/html/draft-liu-netconf-fragmentation
seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-6.ppt
slide 7
KW: There was a draft to introduce pagination in RESTCONF that could be used in
NETCONF. It is done similarly in NETCONF (your 3rd proposal). We might have
issue in RESTCONF because we can iterate over outer list but  not over inner
list. AB: RPC reply needs to be a valid XML document, so arbitrary cutting the
response would not work. Reply should be well-formed, and also valid. Client
needs to know how to do the reassembly. MB: I think the draft addresses a real
problem, we need to limit the depth, it is needed in NETCONF. Bert (as chair) –
do we agree this is a problem? Hum – none. AB: – nice to have. Martin – it is a
problem. Re-hum – now people think it’s something to talk about in the WG BW:
We have lot of work items, AD might not accept new ones. We have to finish
chartered items first. Benoit – you can work in the meantime ME interest of the
WG noted, we need to rediscuss once WG items are completed.

Multi-Instances Configuration Issue in NETCONF - G. Yan (10 min.)
http://tools.ietf.org/html/draft-liu-netconf-multi-instances
seehttp://www.ietf.org/proceedings/90/slides/slides-90-netconf-7.pptx
slide 5
LL: This example isn't valid because routing-protocol is already a list and can
thus accommodate multiple instances. In general, the problem arises only if
multiple instances are not anticipated - the data model has a container where a
list is needed. I think though the proposed solution is too simplistic: it may
not be possible to encode the context in  XML attributes. BW: not clear what we
need to do in Netconf? Seems to do with data modelling. Gang Yan (GY): maybe
separate drafts in Netconf and Netmod MB: It is a big difference if you use it
in the data model or in the protocol. This is a different solution for the data
model. Derek Man-Kit Yeung: You can make the model work for both one and
multiple instances. put in different instances and allow for leaf instances to
be a union JH: IN SNMP, multiple instances was a horrible hack. Push back on
actual models. JS: Supports JH. KW supports the work BW: do we see this as a
problem? In I2RS looks at some of these issues – Gang may look at the work in
I2RS AB: phrase multiple agents is incorrect, different architecture than
multiple instances of a table