Minutes for NETCONF at interim-2016-netconf-1
minutes-interim-2016-netconf-1-1

Meeting Minutes Network Configuration (netconf) WG
Title Minutes for NETCONF at interim-2016-netconf-1
State Active
Other versions plain text
Last updated 2016-05-26

Meeting Minutes
minutes-interim-2016-netconf-1

   Note takers:
    - Susan Hares

Please add your name to the list below:

Attendees:
Kent Watsen
Eric Voit
Juergen Schoenwaelder
Balasz Lengyel
Clyde Wildes
Dan Romascanu
Gary Wu
Mehmet Ersue
Susan Hares
Mahesh Jethanandani
Andy Bierman
Amy Vezza
Giles
Alberto Gonzales Prieto

Agenda:

Agenda of the virtual interim meeting on May 18, 2016, 0800-10000800-1000 FREE
FREE PDT

- 5 min Chair introduction, scribe, agenda bashing
 The notes will be taken on:
 http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim

- 30 minutes. Discussion around how to split the server-model draft.
   [Kent Watsen]

- 30 minutes. Discussion around key-chain model in the server-model draft.

- 30 minutes. Discussion around the scope of each draft in the collection
commonly known as YANG push. This includes updates to RFC 5277.

- 20 minutes. Discussion around zero-touch draft as time permits.

- 5 min AOB other topics

1) Agenda Bashing

2) Splitting the service-model into two drafts

[Slides being presented by Kent Watsen]
Added ietf-syslog into all proposal options from IETF95 as a separate draft
5 proposals for draft split
Proposal 1: 4 Drafts: SSH & TLS Client & Server behavior all bundled
together into a single draft.   Restconf & Netconf in a single draft. 
Different draft for keychain. And Syslog as a draft. Proposal 2: Delta from (1)
- SSH, TLS split into separate drafts. Could be expanded to include other
transports Proposal 3: Delta from (2) - Split layer with the netconf/restconf
Proposal 4: Every proposal gets its own draft Proposal 5: Groups client and
servers

Discussion:
     Balazs Lengyel :  We see a use case for having systemwide tls config for a
     number of protocols. One would be LDAP, so the split looks good. Configure
     TLS 1 and use that for multiple protocols.
    Mahesh:
    Kent:  The devices acting as TLSclient, and connecting to a TLS server -
    may have a specific certificate to authenticate that server.  If the device
    acts as client,  it would have a different set of certificates.   There are
    client-server maps may be used in netconf/restconf authentication-maps.  I
    am hoping to
If you look at the keychain draft, there is a group/list of trust anchors
stored in the keychain. These are use case specific certificates groups (or
lists) - are being referenced both by the TLS server grouping (once by netconf,
once by restconf) This simplifies anyone who is using both RESTCONF and NETCONF
to reference the same certificate list(s) from the keychain model.

 Kent: Does that answer your question?
 Balazs: Mostly.
 Kent: Is there one proposal you prefer Balazs?
Balazs: I am Ok with 1 or 2.

Andy: I liked the first proposal. Typically if i am a developer working on the
client side, I am not reading the server-side documentation.  I would like 2
drafts. Clyde: is this  a motivation to split the model along ssh and tls Andy:
Are we concerned that 3 drafts would change? Is this the primary motivation.
Clyde: I asked because I was looking at perspective of the security group.
Kent: I do not think any of these proposals matter for the security directorate
and reviewers. Clyde: Thank you. Kent: Proposal 2 splits TLS away from SSH. 
While each of those two drafts would contain both client and server models,
each would be broken out into its own top-level section within the draft, thus
making it easy for developers only looking for one to be able to ignore the
other.

Mahesh: Are we looking for minimum drafts?
Eric: I think we should combined drafts as we see it done  TLS and SSH are not
combined.  NETCONF/RESTCONF are often combined in 1 draft.

Clyde: Currently call-home is embedded in the draft.
Kent: Call-home is its own draft for both netcont/restconf. The server model
draft does, in both the RESTCONF and NETCONF modules, define support for
configuring call-home.

Mahesh: Do we have any one proposal we can veto?
Kent: 4 or 5 can be vetoed.
Mahesh: Does anyone have objection to 4 or 5 being removed from consideration.
Sue/Eric: No

Mahesh: We have on the table proposal 1, 2 or 3.
Clyde: Has there been a concern to combine the ietf-netconf-server and
ietf-restconf-server? Kent: There is ietf-netconf-server-model.  It has 5
models.

Mahesh: ... therefore the netconf-server and restconf-server are one draft.

Mahesh: does anyone have a objections to removing proposal 1.
Kent: I think proposal 1 is weak.
Juergen: 2 or 3 over 1.

Mahesh: Let's debate 2 or 3.  Who thinks proposal 2 is fine?
Kent: It is the same amount of work for 2 or 3.
Mahesh:  The differences is netconf/restconf in one draft or two drafts.

Juergen: Is there anything that will be shared between netconf and restconf?
Kent: The key chain will be shared.
Clyde: Is there anything common with call home?
Mahesh: With the consideration of proposal 2 and 3 - is there anything common
between netconf/restconf drafts?

Kent:  two gropings might be sharable: cert-maps and end-point container  -
that are shared between modules. Each of these are defined uniquely.  These
could be factored into a different draft.

Mahesh: Actually .. the consensus on the call was for 2 on the call but there
was a mixture of 2 and 3.

Mehmet: We are not deciding.  It must be taken to the mailing list.
Mahesh:  We'll take proposal #2 and 3 to the mailing list.

Action item: Send the question of the selection of the proposal to the list. 
Summarize that the interim participants preferred 2 or 3.

Topic 2: Discussion around the key-chain model

Issue #2 - How complete do the SSL and TLS models need to be
(slide 12-13)

Discussion:
Kent: Any thoughts?
Mahesh:  Juergen was asking if this needs to be vetted with the sec-dir to
determine if it is complete?   It does need the review for the sec-dir, but do
we need additional review.

Kent: We could take this as an action item to determine if sec-dir cares.
Mahesh: Any other thoughts on this point?

Action item: Review thie SSH/TLS with security directorate.

Issue #3 - How to address the semi-configurable aspects of the keychain model?
(see slides 14-15

Kent: Private keys are not accessible. NACM could specify this.  My response is
that if you did a get, you could utlize a rpc-warning to indicate what needs to
be done.

Mahesh: To summarize, in normal circumstances private keys will not be
available outside the box. Kent:  For keys in the TPM chips, they will not be
available.

Juergen: Why do you have load private key?
Kent: The is not a way to load a private key other than to use the action
statement. Juergen:  If you would be secure, why would you load the private
key. Kent: I know that private keys are loaded in some fashion.  The action
statement performs the load. Mahesh: What is the difference on a security basis
write on a leaf or a action statement.

Kent: I would hope based on NACM
Juergen: By doing an action, you do not allow the loading by using an action.
Kent:  If it is in the model, then the key could be saved to other devices. If
it is an action only, then the action could be

Mahesh: Do you want to make it a write-only option?
Kent: An action can be done against the running data store.  If it is a
write-only option, then it can be done with candidate data store.  Whether the
values were in the start-up data store.

Mahesh: Are we looking for an action or a write-able leaf protected by NACM. 
It would not be mandatory TRUE due to the private keys in a TPM.  A get-config
would need a warning since it would not get private keys.

Mehmet: I would suggest that we propose something and ask if there are
objection. Kent: The proposal is in the current draft to have the private key
as loadable by an action .

Action item: Take to the mail list.  Ask if the action

Topic #3 - Yang Push

Participating:
Subscription model and  5277bis and

(see slides
http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim/netconf-wg

yang-push git used for issue tracking for each draft

Mahesh: Is the attendance open?
Eric: I welcome anyone and I'd be glad.
Mahesh: Balazs wants to be invited
Eric: We'll put an invite on the github
Mehmet: You can put on the mail list that this is an editor's meeting.  If you
invite everyone then it becomes a general editor's meeitng.  You can keep it
private.

Eric: This is what we will do.  We do not have authors.  The people will be
editors if they contributors. Mehmet: You can always arrange an editor's call
for a contributors call.

12:07-12:13
[missed a bit ]
[slide 4]

Eric: The RFC5227bis - do we split the draft into two pieces.  We will want to
have alternative transports beyond NETCONF. Kent:  If the RFC5227bis is
changing the NETCONF, then we need to

[Slide 5]
Eric: There is a base subscription draft.  We are talking about what is the
base subsription draft that can be run over a variety of transports (NETCONF,
RESTCONF and others in the future)  Over that point, we have additional
features for Datastore push.

Discussion:
Mahesh: Is there a model for a proxy on behalf of multiple receivers?
Eric: We have 3rd party subscribers.  This is not a proxy.  IoT make 3d party
subscribers (described in appendix B).

....
Mahesh: You talked about securing the channel, but are you using NACM to
determine who can subscribe to any particular events. Eric: For data store
push, you only have access to the events received on the stream you are logged
into??

I do not know Access control with RFC5277 stream.
It is not given how this maps mechanism in RFC

Andy: NACM applies to the Event types.  NACM allows gating by Event types.  One
of the issues I am concerned about is the performance and speed of this point.
Access control on all content and trying to secure it will be a little slow.  I
suggested that (to speed up

Alberto:  (missed)
Kent: The authorization should be to the subscription. It should not be worried
on the data plane.

Andy: The feature is the I2RS wants is the details in the features.  I think
that the tagging for non-secure transpors that will be included in this
subscription.

Eric: We have custoners wishing non-secure transport.

Andy: People want in IoT -- x  are looking to be extremely efficient.

Kent:  We need to support more than one transport (raw UDP, DTLS, TLS) and
security consideration for the deployments in order to allow non-secure
protocols.  If you are using raw UDP, be sure you are using private network
where the networking is providing the security.

Eric: We are working through issues.  No date for first draft, but perhaps a
month off.

Call-in-user-9:   Where should we send issues regarding this draft?

Eric: Send it to the mail list.  The more people who discuss it the better we
are doing.  See the github repository.

Mahesh: The closer you are to making a draft, the more input on the drafts?

Kent: Is this the end of the drafts?  We have a 1/2 hour.

Balaz (call-in-user-9): Will this be part of the normal netconf data stream.

Eric: I do not think we are going to add a datastore the netconf stream.  We
cannot change the current netconf stream to add more information.

Balaz: The netconf data stream contains all notifications.
Kent: The existing netconf stream is for control-plane.  It is conceptually out
of the question for things related to data stream.  To address this in a
back-wards compatible way, we need to create a "flag" that states that this
notification does not go to a netconf stream.

Balaz: The Yang push for all of data models would be very difficult.  We mark
some of the nodes as non-notifiable. I think this would make it work.

Mahesh: Could this be made backward compatible by adding this to YANG models as
flag, something similar to what Kent suggested above?

Eric: I have not talked a marker to each yang model.  We had assumed that only
some objects would be subscribed to. We assumed that some objects would be
notified on a slow basis.  For example, a counter.

Balaz: We have counters that are changing state or configuration.

Eric: We talked about having a stream that focuses on a particular type of data.

Balaz: We had an operational definition that said "no counters". How do you
define what is a counter?

Eric: I do not recall the operational - except counters?
Andy: The think to look-out for is a feedback loop.  A counter that causes
notification to be sent - which in turn updates the streams.

Eric: Defining on what goes in the streams is important in order.

Alberto:   If we have subtrees that only provide counters - as updates at time
periods.

Balaz: How do you identify what nodes are periodic updates versus others.
Eric: This is part of hte stream definition.  You would filter out these
counters.  As I point out in bullet 3, we need to define streams so that we

Balaz: We are doing configuration mirroring in our management.  It is difficult
to synchronize the who configuration. It would be useful to have a replay
mechanism for change notification.

Eric: We do think that get gives your full configuration.  We do have the
ability to  replay the configuration.

Balaz: Suggest that if you have 20,000 configurations.  It is difficult to pull.

Eric: I see the need.  The ability to store a set of streams so that external
boxes can handle it.  Knowing what needs to be supported, and knowing the replay

Balaz: If we have multiple streams and each stream can determine if it needs
replay.

Eric: Being very careful on what you are archiving.

Balaz: In RFC5277, it is not specified.

Eric: I can introduce you to the call.
Andy:  The current yang push starts out with a full replay and then go from
there.  I think we do not have any input on drops.  We are weak on this point. 
In NETCONF, we do not know if you missed the NETCONF.  I agree with your
comment that you missed.

Kent: In some streams, you do not to worry about dropping (e.g. Counters).  in
some, we need reliable transports.

Eric: Juergen made this point in the chat window.  Having a sequence number is
important. Andy: It is turned off by defeault.

Eric: Balaz - good issue.
Andy: I like the issue of the configuration change stream.  It can be allocated
accordingly.  Different from a general notification. Eric: A full datastore to
describe to is a "non-starter". Andy: The configuration can

Balaz: Next issue. In some situations, you do not want these notifications.  
If a lot of things are changing in a short time.  The notifications are
expanded or notified. Let's say you have a node and a restart. Half of the data
store changed. Can you provide a single notification, instead of a lot changes.

Eric: If we had a notifiacation for susp

Alberto: We had a suspension of change notification. After we change the
suspension.

Eric: We do have a sync parameter on the beginning of the notification.  We
need to figure out a suspend and resume. Andy: We have a suspend and resume on
the server side. Eric: Andy: I am unclear what starts suspend Eric: If the
subscription is overwhleming the client, then client asks for a suspend.   We
could allow for a suspension and resuming.

Andy: I think the resource consumption (e.g. for suspend and resume).  In
NETCONF, the replay buffer is totally hidden. Eric: Maybe there is an OPS
subscription model for multiple models. Andy: You have a subscription priority
that gives a hint on which ones to quit first.

Balazs: My issue is different.  It is not that the node is out of resources. 
It is the case that the breathe of the change is so wide-spread that it needs a
suspend and restart.

Balazs:  I am not sure I want to support notification on startup and candidate
configuration.

Eric: Balazs - this is a very useful.

[Summary of Balazs' input]

Balazs:
    1) Implementing yang-push for every data bit e.g. counters will make it
    difficult for some of our nodes to implement yang-push. I propose to have a
    yang-extension "not-notifiable"  that indicates that for a specific
    data-node datastore change notifications  will not be sent.

2) If I have an on-change subscription and I loose some notifications it is
much cheaper to somehow playback those notifications than to get the full
datastore (or subtree). We would need a replay capability to get the lost
notifications.

3) In some cases e.g. reload, upgrade, etc. there are so many changes that
instead of sending them all, it would be better to : - the node suspends change
notifications - the node sends a special notification
change-notifications-lost. This would allow the client to re-synchronize, read
the datastore with a get

Balazs:

-       Why is XPath filtering mandatory it should be dependent on the xpath
capablity -       Why are notifications on candidate/startup datastore
mandatory. I might have these datastores but still not support change
notifications on them. (specially for startup)

Mahesh: It would be useful for people to review the comments.
Mehmet: When are we going to adopt the new drafts work?  There was an agreement
in BA (IETF 95) when we can adopt these drafts.  We should set a deadline for
final changes to drafts of 1 week.

Eric: There is no need to waits for drafts.

Mehmet: There is one question I have for BIS draft for NETCONF protocol.  The
authors of the orginal draft should be co-authors.

Eric: Two authors are on the call.  I see zero issues as them being authors.

Mehmet: The minimum is that they should actively review.

Mahesh: Anything else before we close the meeting.
Mehmet: provide the meeting link.