Minutes for NETCONF at interim-2016-netconf-1
||Minutes for NETCONF at interim-2016-netconf-1
- Susan Hares
Please add your name to the list below:
Alberto Gonzales Prieto
Agenda of the virtual interim meeting on May 18, 2016, 0800-10000800-1000 FREE
- 5 min Chair introduction, scribe, agenda bashing
The notes will be taken on:
- 30 minutes. Discussion around how to split the server-model draft.
- 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
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.
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?
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
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
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.
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
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
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
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
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
Subscription model and 5277bis and
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
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.
[missed a bit ]
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
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.
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
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
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
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
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
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
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
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
Eric: Balazs - this is a very useful.
[Summary of Balazs' input]
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
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
- 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.