Minutes for the NETCONF WG Session @ IETF 101
Tuesday, March 20, 2018 13:30-15:30
Afternoon Session I
Room: Sanringham

WG Chairs:   
  Mahesh Jethanandani 
  Kent Watsen 

Available During Session:
  Audio stream:  http://ietf101streaming.dnsalias.net/ietf/ietf1017.m3u
  Etherpad:      http://etherpad.tools.ietf.org/p/notes-ietf-101-netconf
  Meetecho:      http://www.meetecho.com/ietf101/netconf/
  Jabber:        xmpp:netconf@jabber.ietf.org?join
  Slides:        https://datatracker.ietf.org/meeting/101/session/netconf

Available Post Session:
  Recording:     https://www.ietf.org/audio/ietf101/
  YouTube:       https://www.youtube.com/user/ietf/playlists
  

AC: Alex Clemm
BL: Balasz Lengyel
EV: Eric Voit
FX: Frank Xia Lian
IB: Igor Bryskin
JS: Jason Sterne 
JSc: Juergen
KW: Kent Watsen
LB: Lou Berger
MB: Martin Bjorklund
MJ: Mahesh Jethanandani
QW: Qin Wu
RS: Rob Shakir
RT: Rick Taylor
RW: Robert Wilton
TC: Tim Carey
TP: Tom Petch


WG Chair Slides

Chairs: udp-pub-channel - what were the updates, given no recent discussion? Were these discussion brought to the mailing list.


Chartered items

Kent Watsen (15 min):
Proposal for Refactoring the Keystore Model
https://tools.ietf.org/html/draft-ietf-netconf-keystore-04
https://tools.ietf.org/html/draft-kwatsen-netconf-crypto-types-00
https://tools.ietf.org/html/draft-kwatsen-netconf-trust-anchors-00
    
Kent presenting.
KW: Any volunteers to help editing keystore docs?
KW: -04 removed global store of public keys; so why is it called a keystore and how might we fix it
FX: Huawei employee, author of several drafts in SACM WG, generally supports work, from Security Area, Will contribute.  Prefers 3, more reasonable for time & discuss what should be included, many possibilities. Should discuss how to work together, need  
RW: Prefers option 2. Publish now. Worry about revisions down the line.
EV: Supports Option 2 as well, supports work going forwards. It might be useful to consider the trusted computing group's definition of trust & anchor
TP: Agrees with RW - against refactoring.  thinks that refactoring is the cause for recent delays.
TC: Agrees that we'd like to move things along; but does'nt understand referencing w/ crypto toward the anchoring, especially for ssh keys. Support publishing now.
KW: It is a mistake. Module does'nt currently have the trust anchor reference to crypto types module

Eric Voit and Alex Clemm (20 min):
Update on YANG Push and Related Drafts

https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-10

Review Q #1:
MB: How is option 2 not redundant from the server list.
EV: Using string for receiver name (options 2 & 3) seems appropriate
MB: Prefers option 3. Feels address/port is redundant in option 2.
EV: There is desire for other dests other ports and some want to config it directly
MB: Option 3 is incomplete; relies on augmentation
EV: Could have both
AC: how do we close.  Prefers option #2
KW: Please spin each question out as its own thread email.
EV: Will create a separate thread for this on the list.  The option of doing either address & port as well as a future leafref to drive the call home mechanism provides a choice.

Review Q #2:
EV: no objection to keeping "subscription-state-notif".  But needs list confirmation.

Review Q #3:
JS: only takes effect on output of publisher?
EV: yes
JS: So how do you know to use it?
EV: If something is in queue, matches HTTP/2 behavior
JS: So a strict priority mechanism?
EV: yes. whether DSCP is an optional feature on its own, or should it be optional in the mainline can be closed on the list
        
Review Q #4:
Option 2 chosen
EV: rename the yang-data containers will be done.

JS: Back several slides. Changes in authorization.  What granularity on auth (filtering within a notification)?
EV: With events do pass/fail test for what event goes on what stream.
JS: If it fails for some portion of an event, the entire even is filtered?
EV: Yes.  Yang push offers greater filtering granularity
JS: If subscription changes, its supposed to be immediate. If the auth changes, it needs to notify event subsystem.  what happens with an external auth server that might not do this (e.g., TACACS)?
EV: Subscriptions can either dynamically update or restart subscription to cause the auth to be updated.
JS: Does'nt really answer the question.
EV: None of this addresses the remote/tacacs server auth, external auth is out of scope in this doc, but useful future work
EV: Need to discuss on list.


https://tools.ietf.org/html/draft-ietf-netconf-yang-push-15
    
JS: What about remote permission reconciliation if off-box capabilities change?
EV: This is out of scope, and has impacts (and requires mechanisms) across all of NETCONF, not just subscriptions 

    
https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-08

<no comments>


https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif

KW: due to the DSCP having a relationship to HTTP/2, should the completion of the LC on these drafts wait for at least a good review of the restconf-notif draft to ensure alignment and implementability?
EV: Sure that weighting and dependency are implementable.  Staight mapping to HTTP/2.  There is code that does this.

KW: When will notification drafts be ready for LC
EV: Waiting to find someone that knows gRPC well enough to ensure it is interoperable with what we have.  Not sure how long that would take.  After 3 drafts complete WGLC, we can assess if we should wait anymore
EV: Author blockers remain primarily the desire to seamlessly integrate with GRPC.  We know the QoS works based on HTTP2 behaviors.  Based on that a delay doesn't seem necessary.


https://tools.ietf.org/html/draft-ietf-netconf-notification-messages

KW: Need to make sure issues are reflected prior to major updates to the draft.
EV: Thought it had been on list.  Look for a dialog from Henk Birkoltz, he is building a new version and will need to socialize issues he wants to champion

KW: Also please update the import from rc:yang-data to new yang-data-ext
EV: happy to do that

RW: have to looked into the size of the data relative to, e.g., gRPC?  Seems like a lot of header fields
EV: Most is optional. Question of efficiency is mostly relevant upon CBOR.  Thinks that identifying all the fields and then determining what to do with them (e.g., bundling) makes sense.
RW: Would be interesting to see the size difference
EV: agreed.
RS: analysis is key.  we have refactored a few times to improve.  done analysis about efficiency (describing ofrmats, path/val w/ compression, etc). Have found a few different approaches that provide better scalability.  Can share results

RW: Good to do an efficiency measure of different transports of this header once the specification starts to settle



Non-Chartered items:

Igor Bryskin (10 min):
Generalized Network Control Automation YANG Model
https://tools.ietf.org/html/draft-bryskin-netconf-automation-yang-01

RT: Support work. Work in dtn wg, brought in by some of the space guys. Not using NETCONF or NETMOD. They are doing it already. There is a whole body of work. Lots of similarity. There is room for collaboration. We would like to the work being done on ECAs and make it fit it with NETCONF and NETMOD. Grab me afters and get some alignment.

TC: Has Juergen seen this?  Because in lmap they have created a YANG model that does similar stuff. Some duplication of work. And the FSM model might address some of this stuff.
IB: Havent spoken to them.  Talked to Andy Bierman. He feels this is a reasonable way to push ECAs. 
TC: I mean; go talk to LMAP WG before going too deep. Tied into IPPM.
KW: Agrees with Tim. Might want to present it in NETMOD.
        
RT: Comment to the chairs. Clearly this is needed in more places; someone needs to drive this work. Possibly in NETMOD.

Mahesh Jethanandani (10 min):
Binary Encoding for NETCONF
https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00
    
KW: If it is a dynamic subscription you pass in an encoding format. As a configured subscription, you pass in both a encoding and a protocol.
EV: Impacts 5277, as it is not used to changes in notifications along the way. So the breath of what is impacted includes dynamic if there is a change after the subscription has started. 
MJ: So the agreement is that we will not be able to support 5277.

MB: If you just encode just the payload, first of all you have to base encode with base64. Then you have to open the RPC blob and do decoding of the base64 data. That does not match the XML schema defined in RFC 6241. The xml parser has to be prepared to parse data that does not match the schema and decode it to match the schema. The only way it would work would be to put the entire encoding in a binary encoding including the message layer. And that goes for notification also. If you change only the payload, it will be tricky.  
MJ: What was influencing us is CBOR doesnt handle the messaging layer. So now in addition, we will have to define CBOR encoding for the messaging layer.

RT: This might be a niave question. But if you are changing the encoding, including the messaging layer, and I take your point about base64 encoding within a XML layer, it is no longer NETCONF. It is another YANG supported encoding. Why have different encodings for NETCONF rather than just say we will do binary configuration?
MJ: Has to do with the need to have a more compressed format for data.
KW: Rather change the encoding, switch the protocol.
JS: I was going to respond to it. You are still encoding NETCONF, just that you are using binary format to encode them. It is NETCONF, just in a binary encoding.
RT: REST is the same. just different encoding.  keep the shape. Perhaps it is just semantics. I do not see encoding the payload, but leave the messaging in its original encoding.
RS: Introducing the unmarshalling, what is the performance of the underlying transport is at the same time. You are going to run into the througput limit of the underlying transport. Why bother with encoding before figuring out if it works well enough without
KW: Primarily Its about high througput or large messages for uses like like telemetry which makes me think about YANG push.

<Lost Audio for remote participants and in the audio stream here for a good 5 min.>

MJ: the draft would have to be updated, so...
KW: whats the level interest for this work:  reason number of hands

<Audio came back, but may have missed comments. If you tried to comment, but could not please indicate it here.>


Qin Wu (10 min):
NETCONF Base Notifications for NMDA
https://tools.ietf.org/html/draft-wu-netconf-base-notification-nmda-00

RW: worth agging push change is delta operation
QW: yes
TC: Should just be bis to nmda, since datastores missed. Should this be a bis to that draft? Why would this just be a bis?
KW: We do not need to decide this now. This draft was published end of Feb. and there was no discussion on the mailing list. It is being presented here, and so this would be something that would have to be discussed as part of whether we want to adopt it as part of the WG.
RW: Would yang-push be a better generalized mechanism for doing this? I question whether this is required. 
KW: It is a notification. And notifications are pushed through YANG push. 
RW: Let me clarify. Whether you need a single notification that something has changed in the operational datastore. Whether it is better to have a generalized subscription on configuration nodes of the datastore. That YANG push is a generalized mechanism for getting notification. 
TC: To answer RW question, this is a case of a broken RFC. You missed this in the datastores that are explicit in it. Fix the RFC. Second is you got a new notification. You want to use the YANG push or use 5277, but that discussion can go on the mailing list. But fix the RFC.
BL: I see value in it. You are trying to transfer information on who changed it, and other metadata like origin. On the other hand you are missing the subscription, you will miss lot of other data. Seems unnecessary to duplicate the functionality
QW: Feels it solves different problems.
KW: Please take this to the list and then we can choose to decide whether we are going to accept this work.
QW: Ok.


Rob Shakir (10 min):
gRPC Network Management Interface (gNMI)
https://tools.ietf.org/html/draft-openconfig-rtgwg-gnmi-spec-00
    
RW: Is the time stamp entered by the hw?
RS: Yes, the target sets the time the data was collected.
LL: You mentioned the models do not have to be in YANG. Do you have other formats?
RS: Yes, we have some models in Protobufs.
TC: How are dynamic elements handled in the yang model conversion
RS: Done in yang-aware models, then serialized
TC: So you lose the "meta data"
RS: Separate idea of modeling vs serialization, the modeling is kept ??


Alex Clemm (10 min):
Discrepancy detection between NMDA datastores
https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02

LB: What new Proto methods are being defined?
AC: rpc to compare
LB: Should be in NETMOD WG since this is not a new protocol.  But useful.  ie: move it to NETMOD?
KW: ok?
AC: Sure.
KW: Who has read it?  <fair number>
KW: Here or NETMOD?  <NETMOD prevails>

Balasz Lengyel (10 min)
YANG Push Notification Capabilities
https://tools.ietf.org/html/draft-lengyel-netconf-notification-capabilities-00

BL: Asking for adoption
KW: Too soon; needs to be on the list and authors have too much work. Should postpone.
BL: Authors support it
KW: I am sure they do.
MJ: will they have time?
BL: suspect i will do majority, but that is a question.

Hauwei emp: Identifying which changes are significant. 
BL: use can use parameters; this is about server capabilities to do it
AC: Think its useful and on the question of bandwidth, because this work was pushed out of YANG push, it is here, and we will make the bandwidth.
jabber (Juergen): Is this right solution for the problem?
BL: There was a simpler solution with YANG extensions, that was not supported. That this is a good solution to the problem. 
BC: I want on change notification for every single variable I have in the router. Even the counters, because some of the counters are important. I think this is important work.
RS: Have same problem in gNMI. Taken a different approach. Some counter should have notification on change. If there a notification for a leaf or a set of leafs that it cannot send, it fails the subscription. You have entered a world where you have a subscription which cannot be met. That leads to questions of compliance. So I prefer we fail the subscription. If you ask for a subscription, and the publisher cannot meet the requirement, just fail the subscription.
BL: orginially it was in schema, but would cost runtime
RS: Annotation in the schema is what can be supported. The question I have is do you want to have the complexity of accepting a RPC that you cannot meet.
BL: i'm saying subscription for everything, but really meaning for all but with these exception. So I am already limiting.
RS: So the contract of the RPC is not met. So our approach is that you the client get to decide what you need, and the server can choose not to accept the RPC. It is clear to the client that the RPC was not accepted. 
RW: Rob Shakir, what happens if you cannot change on every change, but are able to do every 50 ms. How do you indicate that to the client?
RS: If you do give that information to the client, it really does not know what to do with it. So it is better not to give it that information.
RW: So it more about what they are signing up for.
RS: Does it have to be validated. We do not need to carry that as part of the protocol.