Working group status: Assigned jabber scribe, note takers Displayed/explained Note Well Provided a status of chartered WG items since IETF 96 Agenda presentation and bashing Provided an updated of milestones (no objection noted to milestones presented) Andy Bierman: 8-12 months to update the draft (RESTCONF Collection Resource). Mehmet: 8-12 months is too long. Andy: Perhaps we can just drop it for the moment. Mehmet: Can we put it on hold? Conclusion seems to be to put it on hold. Benoit Claise: Can put it on hold, but a difficult choice. Whether we do it now or later we reach the same conclusion. Until people agree to do something that nothing happens. Perhaps just send the status to the mailing list, or perhaps find a new editor. Mehmet asks room: Who knows this draft? Just a few hands shown? Mehmet asks room: Who is interesting in continuing this work? Just Kent. Kent: RESTCONF is an incomplete solution without support for very large lists, this needs to be done sooner or later, otherwise there will be lots of proprietary solutions. Mehmet: Not keen on dropping this .... Andy: We have the same problem in NETCONF (i.e. large lists), and it doesn't seem to be an issue there. Do we need to do this work? Mahesh asks room: Who is interested in working on the draft? Kent showed interest in working on the draft after the current set of drafts he has on his plate. Lada: Agrees that pagination would be useful, perhaps some existing RESTful solution can be reused? Kent: Clarification, are you saying that we can just leverage an existing solution? Lada: Yes. Kent: One of the co-authors already has such a solution, the aim now is to make it standard. Mehmet: We will take this to the mailing list Benoit: Nice that Kent wants to work on this, but it shouldn't be a top priority. Keytstore is the top priority Mehmet: Will decide on a milestone later. Chair noted that based on dependencies Keystore draft is important to complete Chartered items: 1. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen (15 min.) https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-11 Kent presenting: Noted that there were no formal issues open but there might be a problem with the complexity of bag of CRLs; use of CMS vs PKCS#7 and if the operators would even accept the solution Ian Farriar: DT believes there are places where this can be useful Bob Moskowitz : You should look at doing an OpenSSL implementation. I've done signing certificated on OpenSSL. This is a cheap solution that you would never deploy in a production deployment but it provided that the technology works. Kent: When saying operators he meant the larger community including enterprises. Asked for clarification if the should be a reference implementation using OpenSSL Bob: I would think so, you can pretty much do all of this. Used a mail server as an example. Kent: There is an example in github, but currently isn't usable, but I would try and make it so.??? Kent: ???Question to Ian, what was it???? Ian Farrer: ? Ian Farrer: RFC7223 gives an example. This won't work for DHCP4, so will end up with a more complicated example. Kent: This can be a new open issue that will be addressed. Was hoping that both these cases could be handled in the same way, but they will need to be slightly different. Ian: ??? Kent: I'm not a DHCP expect, there might be a similar issue related to a DNS server. Hopefully a DNS expect in the room that can help review? [No one in the room offers] Benoit: Take it to DNSOPS mailing list, just reach to those guys. Kent believes the draft is ready for last call. Kent asked if any has implemented or plans to implement the draft Rick Talyor: I want to implement this, but it is a better further down the line. Andy: Indicated significant interest in call home, zero touch and server modules Radek Krejci: We are working on it. Bob: I'm coming from DOTS WG, discussion about whether they will use their own protocols, or use RESTCONF or NETCONF. DOTS have the problem of inter organization trust issues. Trying to work whether Kent's draft helps with this. I.e. can DOTS use this draft, or learn from it. Mehmet: Please can you take this discussion offline, but take it to the mailing list. Kent is asking for last call, so please bring any issues to the WG now. Kent said he would like to got WGLC after the next update Mehment: Noted that there is support to go to WGLC Server Model Drafts: ------------------------- 2. Keystore Model - K. Watsen (10 min) https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 Kent presenting: Keystore draft is highest priority, so will focus on that draft. Kent: Asks for questions. [No questions] Benoit: Are all drafts waiting on Keystore or something else Kent: No there is other work to be done other than Keystore 3. SSH Client Server Models - K. Watsen (5 min) https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-01 4. TLS Client Server Models - K. Watsen (5 min) https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-01 5. NETCONF Client Server Models - K. Watsen (5 min) https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-01 6. RESTCONF Client Server Models - K. Watsen (5 min) https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-01 All server model drafts above were presented together (notes under "Keystore Model"). NETCONF Notification Drafts: ----------------------------------- 7. Subscribing to YANG datastore push updates - Eric Voit (15 min) https://tools.ietf.org/html/draft-ietf-netconf-yang-push-04 8. Subscribing for Event Notifications (RFC 5277bis) - Eric Voit (10 min) https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01 9. NETCONF Support for Event Notifications - Eric Voit (5 min) https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-01 10. RESTCONF & HTTP Transport for Event Notifications - Eric Voit (5 min) https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-01 11. NETCONF Access Control Model - A. Bierman (10 min) https://tools.ietf.org/html/draft-bierman-netconf-rfc6536bis-00 Eric Voit presenting: Mehmet: Clarified that the design team is informal team open to anyone, not chairs/AD organized. Informal design team has met 14 times, meetings/recordings are available on Github site (as per slides) Jason Stern: Regarding dampening, there might still be some inconsistencies in the draft. These have to do with per-object dampening still appear in the text. He will mail out where he saw this. Eric: Please point out those inconsistencies on the mail list Eric: Asked if the streams need to be optional or mandatory (no opinion from the room) Eric: There is an issue with filtering on meta-data - basically, complex intersection filters across various forms of metadata are not framed. Issue is independent of subscription. Expect something to mailing list when fully articulated. Andy: Discussed filtering based on topics instead of data or content. Topics would be based on YANG identities Andy: Is there interest in this type of filtering, to create a topic tree, next to the model tree Kent: Requested clarification of topics Andy: Correct Kent: Requested clarification how this related to YANG PUSH Eric: A topic would be a filter on the data that is returned. Andy: Critical has been dropped. Rick: Adding metadata labels, but adds a load on the to the servers. Andy: Yes, it does add a load on the servers. Eric: Topic filtering will be a future work if there is interest Rob Wilton: I think that adding a sequence number would be a good idea. Eric presenting on RFC 5277bis Eric presenting on Restconf/HTTP2 Rob Wilton: Asked if support should be HTTP2 mandatory and HTTP1.1 optional Eric: Requested help in aligning the protocol with gRPC Benoit: [is nodding head]. There is someone in this room that knows gRPC pretty well. Mahesh: Eric has already left. Benoit: Will introduce over e-mail. Eric presenting Notif-netconf Eric asking room: Do you have any opinion of Call Home via a known port?? [No comment from the room] [No futher questions] Mehmet: If no open provides any comments then the solution proposal gets adopted, please can everyone provide their comments and opinions on the solution proposal. Andy: If the design team didn't exist, there were still be drafts to review, nothing in the process has changed. 12: NetworkConfiguration Protocol (NETCONF) Access Control Model Andy Bierman presenting Dean Bogdanovic: Can we use NACM with schema-mount? Andy: We will see if we need any edits here, or if we can keep that complexity in schema-mount. Andy: Noted 2 issues left Schema Mount and I2RS Dean: Two new cases, one to see through the whole tree, (2) black boxes, child can't see into the parent, parent can't see into the child. Martin Bjorklund: WG needs to adopt the draft first. Mehmet: Needs to understand all the issues with I2RS before adopting Andy: One issue is assigning priorities to clients, second issue is related to access control on the dynamic datastores (e.g. I2RS) Lada: Noted an issue in RFC 6536 with parent/child relationships that's important for RESTCONF. For example, if a client has read access to a target node, does he also have read access to the ancestor nodes in order to be able to read the target node's data? Is this addressed in new draft? Andy: Can only select from subtree down, in RESTCONF I can set the target URL to a subtree. Lada: It would be good to clarify these cases. Mehmet: Maybe sections that address the I2RS and schema mount issues noted Mahesh: NACM has tried to solve Authentication and Authorization, but is silent on Accounting. This is an issue for our customers. Is there a standard defined for Accounting records. Is there interest in this working group to try and formalize what an accounting record would look like. Mehmet: Asked if there was interest in an accounting format (group showed interest) Ashesh (From Ciena): If this group does not define it, someone else will. Juergen + Martin + Balazs: Accounting should not be done in NACM; use a different draft Martin: Authentication is not done in NACM, it only does Authorization Dean: Clarified authorization from Authentication and Accounting from authorization Non-Chartered items: 1. Voucher and Voucher Revocation Profiles for Bootstrapping Protocols - K. Watsen (5 min) https://tools.ietf.org/html/draft-kwatsen-netconf-voucher-00 Kent Watsen presenting: Kent asked if there were any comments on the encoding issue (no comments; taking it to the list) Rick Taylor: Signing makes a point encoding (CBOR/YANG) Kent: Doesn't matter once it is in a file; its just signing the file. Mehmet: If you have any comments here - please bring them up on the list Chairs noted that it might make sense to keep Dean B: Other workings might have better use cases for the vouchers; although they can bring back those needs here Mehmet: Does Anima have any other use case documents that explain voucher uses Ken: Use and no; actually zerotouch does have some use cases Mehmet: Who is interested in working on draft in NETCONF? (5 people) Dean: Interested in working on the draft Benoit: Need to see from the Security ADs if anything (use cases or work) has been done on vouchers Mehmet to Benoit: What would be the direction on how to determine which group would adopt the draft Benoit: Need to coordinate this with the leadership of Security AD, Anima and 6tisch 2. Datastore DT Discussion - Phil Shafer, et.al. (45 min) A Revised Conceptual Model for YANG Datastores https://tools.ietf.org/html/draft-nmdsdt-netmod-revised-datastores-00 Rob Wilton presenting: Mahesh: asked if anyone here has not seen this presentation in NETMOD so we can focus on REST/NETCONF details Lada: Dynamic configuration is shown 2 is this a mistake Rob: No - it dependent on the origin Jason Sterne: Origin is good; noted the fix to operational-state Mahesh: Show of hand of supporting the solution into the netconf (very good support) Rob Presenting Protocol implications: Asked for comments on the datastores needed in NETCONF Kent: Asked clarification for if op-state was required Rob: ? Rob: Questions on how to return origin meta-data Martin: Leave get-config as is Rob: can we deprecate as its obsoleted by op-state Parviz Yegani : are datastores consistency in the draft Rob: Yes Parviz: Asked if there was consistency between multiple devices in drafts Rob: No Parviz: Does latency become an issues Rob: Doesn't believe latency would be an issue Eric: Eventual consistency is the goal; latency isn't the issue Parviz: ? Rick Taylor: Clarify get/getdata if op-state is support; its part a capability not sure what the question was.... Jurgen and Martin and Andy: get has a certain semantics; cant change it Andy: shouldn't be deprecated Rob: Solution solves more than latency Martin: works fine with existing data models but not new ones Sue: What datastores does validate apply Kent: Validate should apply to the new datastores Rob: yes the datastores are intended applied and opstate Mehmet: Take it to the list Presenting RESTCONF implications Andy: RESTCONF needs to remain simple opposed to changing restconf Kent: The change is necessary for future data models where the -state part of the model no longer exists. Andy: ? Mehmet: Need to validate support for document on mailing list; to NETMOD chair are we send work progress to both NETMOD and NETCONF list Lou: Yes - It will go to both lists but the process needs to be run from one place Mehmet: NETMOD is the home Kent: Should we just CC NETCONF Lou: one message to both list and please discuss to both lists Andy: There are no drafts so there isn't any work for NETCONF Benoit: Charters will need updated of there no objection to the work Session ended...