Note takers:
    - Ladislav Lhotka [LL]
    - Jason Sterne [JTS]

Jabber scribe:
    - Mikael Abrahamsson [MA]
    
Speakers:
    - Andy Bierman [AB]
    - Mehmet Ersue [ME]
    - Mahesh Jethanandani [MJ]
    - Kent Watsen [KW]
    - Rick Taylor [RT]
    - Jeff Haas [JH]
    - William Lupton [WL]
    - Martin Bjorklund on Jabber [MB]
    - mcharlesr on Jabber [MCR]
    - Guangying Zheng [GZ]
    - Tim Carey [TC]
    
Joining via Jabber:  23 people
Joining via Meetecho: 12 people

Agenda bashing (2 minutes)   
WG status review (5 minutes)

Chartered items:
      1. Report from documents after WGLC: Restconf, Yang-patch, Yang-library - A. Bierman (10 min.)

      AB: 3 drafts are nearly ready.  
          RESTCONF needs some updates based on comments from Tom Petch
      ME: Are you going to address all comments? Any controversy?
      AB: All the open issues are minor, it shouldn't be a problem.

      2. Subscribing to YANG datastore push updates - Eric Voit (15 min)
         https://tools.ietf.org/html/draft-ietf-netconf-yang-push-02

      KW: I recommend splitting control and transport.
      MJ: Does anyone oppose the concept of splitting transport from the data model / RPCs ?
          -> In the room:  Nobody was opposed.  Many were in agreement.
      KW: Subscription allows for periodical subscription, how about other filters (e.g. when a value is exceeded, or when a value changes by more than a standard deviation, etc)
      EV: TBD on how much to put in the base model (many types of filters are possible)
      RT: Request to look at what is being worked on in DTN (async. mgmnt concepts)
      
      3. NETCONF Server Configuration Model - K. Watsen (15 min.)         
         http://tools.ietf.org/html/draft-ietf-netconf-server-model

      JH: Security people will likely want some additional security functions as "if-feature" options in the base draft
      WL: ?? Clarification question about the use of groupings
      MB (jabber): propose to keep the SSH config knobs to the minimum
      ME: for issue #5 in the slides -> I'd suggest Proposal #2.
      KW: Proposal #2 means we need to specify the client part immediately.
      MJ: is there a need for a common keychain model across WGs ?
      KW: routing keychain is fundamentally different than the one needed in this draft
      MJ: It currently relies on NETCONF security (SSH/TLS) to push keys.
      KW: some concerns that strength of key being exchanged is higher than strength of security on the channel/protocol being used to exchange the keys (known issue)
      ME: What are we defining for NETCONF WG? Is it something of interest to general security of just something for NETCONF/RESTCONF?
      ME: any objection to moving forward on a NETCONF keychain independantly of the routing keychain model ?
      RT: I undestand appeal of #1, but I don't understand how you can avoid dealing with clients. I propose to use #1.
      KW: would boxes be making outbound connections like SSH, NETCONF, etc ?  If so - proposal #2 is useful.
      JH: NETCONF/RESTCONF requirements overlap general reqs.
      MB (jabber): I support #2.
      KW: there seems to be a lot of support for #2.  Will take it to the list.
      MB (jabber): peer mount would use (? client side config ?)

      4. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen (15 min.)         
         http://tools.ietf.org/html/draft-ietf-netconf-zerotouch
		

      RT: I would go for option #3 (slide 10) - use edit-config or yang-patch. The configuration can be big.
      KW: maybe an another option is to use a top level enum instead of a flag to allow a 3rd choice (patch vs just replace or merge)
      KW: any thoughts on signature over the YANG data ? (slide 11) 
		 JH: PKCS#9 is popular in the IETF. Canonicalization is going to be arequirement.
		 KW: Namespace issues, both XML/JSON has no guaranteed order.
      JH: storage formats have changed immensely over the years.  Fixing them in the model will likely just make the model obselete quickly . Maybe a registry ?
      KW: What would be the motivation? 
      MCR: Not that we define them, we should just refer to them.
      RT: what are we trying to achieve here ?  Just basic booting ?  or more ?
      KW: just trying to boot & be ready to be managed.  But the difference from previous approaches is that this is a *secure* approach.  In theory the config could be anything (huge full config) but it needs to be at least enough that the device can make a management connection for further management.
      ME: please propose a way to move forward on this draft
      KW: My hope is to have LC in one month and finish this work in 2016.
      
      5. NETCONF Event Notifications - Eric Voit (15 min.)
         https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-01  

      AB: It would be good to consider the ability to do next gen filters (current ones have limitations)
		 EV: There has to be a base set and optional extensions.
      AB: Another dimension of complexity is the concept of a template for filters 
      EV: We have case of XPath and 6241 filter. Filters are important.
      RT: some of the work within DTN may be reusable here (but may be a bit more than is required)
      EV: Filters is scary, we took existing ones.  This may be a space for vendor differentiation (at least at first) and then move more advanced filters into the standard at a later point
      ME: Can you report on discussion with former authors?
      EV: static subscriptions can be more complex (configure the receivers, origination comes from the source).  May need to think about call-home.
      ME: Is the recommendation to keep compatibility?
      ME: It is important to have Hector and Sharon as part of the review to ensure backwards compatilibity
      MJ: Is it a new work or 5277bis?
      EV: I think we added items that are within the charter.  When does a bis become a new standard ?
      ME: If we keep existing functionality, it should be 5277bis. It is a chartered topic in any case.
      ME: Let's continue the discussion with orig authors, after a few weeks we can ask for adoption.
      EV: are notifications of interest in general ?
         -> show of hands of who read the draft ?  A few hands
         -> how many people have interest ?  many hands raised in the room
      GZ: we have some implementation of notifications and would want to sync up on the draft

Non-Chartered items:      

      1. I2RS strawman proposal - S. Hares (15 min)
         https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-00  
        JTS: What is teh issue with CPU resources and memory:
        DB: I may want ro set a memory limit. Eg. a network topology poll, you may need to specify mem limit.
        JH: You may want to specify rate of notifications.
        JS: Specifying BW and memory in absolute terms is tricky.
        JH: It is just that some resource considerations are taken into account.
        JH: Discussions about mandatory transports.  There will be mandatory-to-implement transports, but also hooks in the initial base model to allow other future/optional transports & encoding.
        
      2. Restconf subscription and HTTP push for YANG datastores - Eric Voit (15 min)
         https://tools.ietf.org/html/draft-voit-restconf-yang-push-00
		

		ME: Comments about the name - it's not YANG Push
		KW: NETCONF Push for NC, RESTCONF Push for RC.  Proposed names for the 3 models:  netconf-push-transport, restconf-push-transport, and yang-push-model  (murmurs of assent in the room)
		KW: It's not a WG document.
		AB: Separate subscriber and receiver is interesting. There are 3 parts: 1 - data, 2 - interaction model, 3 - plumbing. I want to be able to conform to 1 part of it but use my own things for the others.
   RT: keep the specs modular.  We need to use as much "standard" parts as we can, but be able to use other transports/encodings.

      3. How many drafts for YANG push? - All (10 min)  Open       
ME: There is interest, chrter doesn't make any difference between NC/RC Push, we have to discuus what to do. Is it correct RC-YANG-Push is mainly transport?
MJ: there are 4 drafts (5277bis)
ME: what does the group think ?
TC: we've seen this in other standards bodies - the need to separate the operations layer from the transport/encoding layer of the protocols.
ME: Misleading picture - why I need NC if I want to use RC?
ME: show of hands -> do we want 4 drafts ?  (yang push, NC transport, RC transport, 5277bis).  Lot's of hands for "yes". None for "no". 
ME: Adoption should happen within a few weeks.
ME: We need co-authors from other companies.
EV: Agrees.
ME: We may ask by name to co-author, e.g. Juniper people.
AOB