NETCONF 94 Agenda:         - draft-leiba-netmod-regpolicy-update (3 min)        Asking room for capabilities in iana registries move from rfc required to expert reviews?    Mehmet: Any objections from within this working group?      Benoit: Do we want to allow ability to create IANA registeries with expert review?    Dan Romascanu: Needs to review the document, but does not see a problem. No objection raised to proposal in Barry Leiba draft The process in the leiba-draft will be then used in future for non-standard capabilities in the registry. Benoit: Time capability draft is a AD sponsored draft Benoit Claise: There was an AD sponsored netconf capability draft that needed IANA actions. Joel suggested to have an experiment with registry update process. We wanted to change the registration process for the capabilities. We are asking whether it would be possible to not use the IANA registry and instead to use the expert review?  Mehmet: has anyone read the draft? Do you have any comments?  Benoit: do we want to have capabilities for experiments?  Dan Romascanu: [missed, see above] Benoit: the draft is already published. We do not want to disturb the WG if there is a limited consensus.    Non-Chartered items:       1. I2RS strawman proposal - S. Hares (20 min)        Sue Hares presenting.  Mehmet: what about next steps? what is planned for the next time?  Susan: any questions, complaints? [no response in the room] Sue: our first goal was to figure what to do with the minimal requirements. If the effort looks good we will work with netconf wg to define the full protocol.  Sue: Action item 1 - what to do with requirements.  Mehmet: let's discuss next week to align with the upcoming protocol work.  Sue: please tell us what we need to add into netconf protocol. Jason Sterne: is the idea that ephemeral always takes priority over config?  ephemeral always wins, not last one always wins.  Does an operator has a way to overwrite / preempt ephemeral Sue: higher priority clients can overwrite lower priority clients Jason: slide 12: is scheduler client prirotity checked/ compared vs ephemeral?   do you see any mechanism for operator to override the ephemeral Sue: the client can be overridden by higher priority clients. You can delete the ephemeral and then the config will take over. You can do both config and ephemeral at the same time.  Jason: you have a management interface. Does it have a pririty?  Sue: the client in the picture is the I2RS client.  Jason: my understanding the top level was management interface,  Sue: it is I2RS capable management client.  Jeff Haas: is there any way for static? to win? No, not at this time. We do not allow for infinite sets of overlays, no infinitely deep panes of glass model.  Jason: my point was about the ability for operator to override the ephemeral decision. Jeff: that is understood, and this should be done via config/CLI mechanisms.  Jason: I am referring to the ability to override.  Jeff: one of the things considered was whether some mechanism of tagging the ephemeral as not being overridable.  Sue: that potentially can be used in your scenario, config could be higher priority than ephemeral.  Balasz - jabber: are lower priority ephemeral config operations stored, or are they silently ignored?  Sue: excellent question - get on the list - related to caching  Sue: please get on the list and discuss this.  Sue: if you really think you must have ephemeral state, that's not in hte model.            Chartered items:       1. Subscribing to YANG datastore push updates - Alex Clemm (10 min)          https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00 Alberto Gonzalez Prieto presenting Martin Bjorklund: Why do you have different ways to structure encodings - why not use YANG-patch for both? Maybe specify another option to indicate user preference for encoding style Alberto: good suggestion, will consider Martin: why do you have different ways depending on encoding? Why not use YANG patch for both? Alberto: we thought it would be more intuitive to use NETCONF approach and not the RESTCONF approach.  Martin: maybe you should first define patch style, and then encoding style?  From Jabber Andy Bierman: if the client is not the same as receiver - what protocol is used there?  Alberto: [missed] Jeff Haas: we think that sending to more than one station is needed, multiple receivers could need different encodings though.  Also, Receivers should be able to select their own encoding Alberto: receivers should be able to tweak the subscription parameters.  Benoit: what is the interaction between this and update notification document?  Alberto: we had to change the semantics of subscribe time?? Benoit: I am still waiting for update of 5277bis?  Alex Clemm: We didn't want to extend the semantics in this document. Benoit: Anyone working on 5277  bis in charter? [a: not yet] Benoit: is there anyone in the room working on 5277bis? Not yet.  Mahesh: is there a requirement for receivers to be able to request the notifications midstream? Alberto: the receiver can tweak the parameters, If you are talking about the subscriber, that is something that the ? can do. There is nothing that mandates that.  Alex Clemm: when you have multiple receivers that want to tweak their parameters, that should be multiple subscriptions, otherwise it is too complex.  Martin: why not use call home for multiple subscriptions? Alberto: yes, that is possible.  Jeff Haas: call home is one of the cases that we need to support in the base profile. We have customers that will want to use alternative formats; e.g. grpc and protobufs.  Motivation for asking whether you can tweak the receiver parameters - if you have those, serializing the protocol on the wire is the easy part. SNMP traps can be an example - once you have a schema, transferring is just a serialization.  encoding might even be grpcs or protobufs Jabber - Balsalz Lengel: will replay be supported from push Alberto: right now that is not supported.  Mehmet: would it be good to support?  Alberto: good input, will think about it.  Alex Clemm: it would be good to support, but need to know the requirements. You may have use cases that need to get the most recent? response? (many applications may not require raw replay, they want just the most recent -there is overhead associated with replay ability - does not make sense to store/retain updates for replay for longer time) Martin: if you do not have the subscription, you do not know what to replay as you do not have filters, you would have to buffer all.  Alberto: it is not good to mandate to support always.  Jeff: we talked about this in the context of I2RS traceability for retrieving the subset of data. If the data is cached, it can be replayed, but need not to cache too much.  Mehmet: we are running out of time.  Martin: [missed] Jeff: timestamps would be an example.  Andy - jabber: we do not replay what we have stored in the past.  Andy - jabber: what does it mean if start time is in the past Alberto: in this case, subscription starts immediately.  [Alex Clemm note: also, time in the past still serves as anchor for periodic subscriptions- in that case, the next update will be sent on first interval from the start time)       2. RESTCONF & Co. - M. Bjorklund (45 min.)          - RESTCONF Protocol  Martin Bjorklund presenting. Kent Watsen: the spec requires realm to be sent by the server, but we do not specify what realm should it be, either user configurable, or hardcoded. Realms are used for virtual hosts and do not foresee that RESTCONF server would be used in that context.  Martin: this is an open issue for the WG to decide Tim ...: Why can't this not be part of a virtual host ?: restconf server can be a part of virtual host - would be applicable? Kent: the server runs in VM but that is not the issue as the server's context is a single host.  Kent: we can just stop sending notifications. We also have a callhome type of connections that could be used here. Martin: the other question was how would the client actually stop it Jeff: I would be careful with just dropping the TCP session, it may end up in a mess. There should be a clear notification to stop.  Tim....: There needs to be a clean way for client to request notifications to be stopped.  Not just drop connection Jeff Haas: seconding what Jim said. Transport session can just go away for unknown reason.  Kent: servers and client must be coded to handle drops of transport sessions, if they don’t do that then it is implementation issue.  Jeff Haas: this is intent question.  Martin: need to resolve this on the list Mehmet: is this seen as an open issue?  Martin: this seems to be an open issue and we need to find a solution.  Kent: there is one more issue on authentication - any authentication mechanisms is allowed but does not specify which one must be supported. We need it specified for requesting client certificates. Some draft that was referenced is expired  Mehmet: our plan was to LC next week - do you think it is possible to close those issues in 1-2 weeks?  Martin: we need to agree on the open issues - subscription/notification thing, how to do in a nice way.  Kent: we need more discussion.  Mehmet: good.           http://tools.ietf.org/html/draft-ietf-netconf-restconf          - YANG Patch Media Type   Martin presenting.  no questions and comments.           http://tools.ietf.org/html/draft-ietf-netconf-yang-patch          - YANG Module Library            http://tools.ietf.org/wg/netconf/draft-ietf-netconf-yang-library/ Martin presenting.  [updating the slides as the ones presented are not current] [slides presented are draft-ietf-netconf-yang-library-2.pdf] Jeff Haas: an example could be I2RS - we are trying to define how to do it in netconf and restonf, but restconf will be first. netconf is not guaranteed to be supported.  Martin: yes, we need to look at this also on the list, need to add something to datamodel to support this Sue Hares/I2RS chair: how much more can you simplify - what is the level of granularity, only restconf/netconf, or more than that list? Are you thinking about the granularity deeper than the module level?  Martin: Would have to be extensible list Martin: the idea is to do this at the module level.  Different idea would be to have protocol-specific instances of modules.   there can be protocol-specific instances of modules  Jabber - Andy: does restconf have to implement module ietf-netconf.  Martin: that was another example - would say no Jeff Haas: requirement for I2RS - if the module implements configuration state and operational state, that operational state may noit be only I2rs state. Do we need any mechanism to try to separate that?  Martin: we need to think about this.  Might be easier to view this as a sepparte instances, in this case we don't need any additions, just clarification Martin: maybe would be simple to view it as separate instances per protocol, and the we need no additions.  Mehmet: plan to go to WGLC with all 3 drafts as a package.  Please try to finalize in 2 weeks Martin: need to work out the issues on the list first, and require review Mehmet: can you finalize the issues in next two weeks?  Martin: we will work on a list as that involves many authors. Lada: restconf depends on YANG 1.1  Martin. And YANG 1.1 depends on YANG library.  Lada: some preliminary conclusion was to target December 1st.  What is the YANG 1.1 schedule?  Lada - Dec 1st  Mehmet: restconf cannot be published before yang 1.1  Mehmet: going to wg lc is our first step.  Martin; nothing stops people from reviewing docs and send comments in the meantime Mehmet: let's work on the solutions and bring on the list.  Mikael Abrahamsson: the last slides do not seem to be uploaded?  Others: they are there.  Maybe confusion about where       3. NETCONF Server Configuration Model - K. Watsen (5 min.)          http://tools.ietf.org/html/draft-ietf-netconf-server-model Kent presenting.  Kent asking: has anyone read this and comments? Jeff Haas: I have not read it. Are you aware of Acee's work on this subject too?      Kent: there are other keychain oriented drafts - 3 or 4 - not overlapping with this.  They are not system-level keychain models, oriented at router.  but, may have missed some comments when those were discussed.   Mehmet: whether it makes sense to split it into 2 parts - keychain and the rest?  Kent: concern is that groupings have leafrefs into keychain model, if you send this to other WG you have dependency, would need this to stabilize.  Could split into documents - but there is still the dependency - splitting may not be helpful. Martin: just split the documents? Kent: there will still be a dependency. Mehmet: If you do not think splitting is helpful, then how long do you need to prepare the solution?  Kent: There are some issues that are missing.  Clearly it is a complex topic.  Therefore cannot answer the question how long to complete.   Mehmet: I do not need to hear a deadline, just the indication.        4. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen (20 min.)          http://tools.ietf.org/html/draft-ietf-netconf-zerotouch Kent presenting.  Kostas Pentikousis: why would the new device not be able to reply to the NMS? It is initiated from the device, there should be no problems for communication? Not questioning the design, just want to understand whether there are any requirements to do that?  Kent: maybe for convenience and simplicity in implementation.  Very few NMS support call home today, many support initiated connection, so this fits more easily with existing implementations.  But nothing forces to do it in a particular way.   Max Pritikin: one of the places where we need to look and see what happens in the local network is the DHCP redirect server? There is overlap in discussions with ANIMA approach.  Kent: right.  This diagram does not illustrate what Anima might do.   Mahesh: how many operators are there in this room. Of those, how many would want to implement a solution like this?  Mahesh: how many have read the draft? Please provide context  4 operators, 2 out of 4 would implement Mahesh: can we have show of hands of operators that are interested in this type of solutions.  Max Pritikin: I will indicate that the updated draft to cover the loose ends is rather large.  Kent: thank you   Non-Chartered items:       2. Restconf subscription and HTTP push for YANG datastores - A. Clemm (10 min)          https://tools.ietf.org/html/draft-voit-restconf-yang-push-00 Alberto Gonzalez Prieto presenting.  Mehmet: I would like to hear pro and contra concerning having one or two drafts. My personal view is that two drafts need to go as twins.  Alberto: after the LC we can define a different extension.  Alex Clemm: the issue does not seem to be the bundling of the release date / releasing them together . Should be release together.  Still, each can be separate, this will be easier to assess, less options, and then they could be released together. Editorially separate.  Mahesh: can the authors repost the drafts with the correct names?  Kent: I think there should be 1 or 3 drafts. 3 would be - one for generic pub/sub, other for NETCONF and one for RESTCONF.  Martin: it is not easy to read two documents. It adds to the noise. Better merge.  Mehmet: what is your preference? Martin: my preference would be one, otherwise three.  Alberto: what about the conformance?  Martin: I do not think that is a problem. Now the data model is duplicated in two drafts, and that is almost the same data model.  Kent: both callhome and subscription drafts have to do the same with netconf and restconf. Mahesh: how many people would prefer to have single draft? How many three? How may would prefer two?  Mehmet: we should discuss this offline, there is no obvious winner. The current chanter covers the topic. Do people like to address this issue in this group, or not? When we converge on this agreement, then we can address whether it is 1 or 3 drafts.  Mehmet: who in the room is in favor of addressing this issue in the netconf wg?  Kent: we already adotped netconf push. Given that, is the question that we want to adopt restconf yang push?  Mehmet ... Martin: in the charter it says only netconf push.  Mehmet: charted does not mention restconf or netconf.  Martin.   Mehmet: this is a new draft with new cointent.  Mehmet: please show hands is you in favor to address this in netconf wg. Nobody against. Many hands for.  
 7 hands for single (did not count the others) - Mehmet: no obvious winner, charter covers the topic Mehmet: are people supporting this particular topic (quite a few hands for (between 12 and 20?), none against)  Mehmet: we take this to the list, and then you can provide the corresponding draft. This agreement needs to be verified on the list - this is a process step.    Open        AOB Mehmet: is there anything else to discuss?  Kent: Update on the callhome work. It is currently in IESG. Except of Stephen Farrells DISCUSS all other have been closed. Met with TLS co-chairs to get agreement. I am hopeful that - it describes what we described verbally - that they agree with that. Will inform the list when I get back from them.  Kent: Github review procedure. Do we need to do another LC on that draft?  Be  Benoit: that is a good point. If there are major changes, then maybe the WG should review it again. If that requires time it is fine.,  Mehmet: such issues need indeed to be brought to the mail list Kent: my plan is to post the updated document and bring the discussion to the list Mehmet: will be reviewed on the mailing list Benoit: either you do it - the review, or you do a formal LC.  anything that works is fine Mahesh: end of meeting.