Minutes IETF97: netconf
minutes-97-netconf-00

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...