Subject: [Netconf] Minutes from IETF 97

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 1 Dec 2016 12:48:10 -0800

First of all, the chairs would like to thank the note takers from IETF 97. Folks who presented or who came to mike might want to look at the notes to make sure their comments were accurately recorded.

Please note that you can only update what was said in the meeting. These notes and any updates received by December 8 will form the final minutes.

Thanks

Mahesh & Mehmet

----------------------------------------------------------------------------------------------------------------------------------------------------------

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 <get> 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: <get> shouldn't be deprecated
   Rob: Solution solves more than latency
   Martin: <get> 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…