Agenda for the NETCONF WG Session in IETF 106 --------------------------------------------- Session: 15:50-17:50 Monday Afternoon Session II Room: Olivia WG Chairs: Mahesh Jethanandani (mjethanandani at gmail dot com) Kent Watsen (kent plus ietf at watsen dot net) Available During Session: Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1064.m3u Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-netconf Slides: https://datatracker.ietf.org/meeting/106/session/netconf Meetecho: http://www.meetecho.com/ietf106/netconf/ Jabber: xmpp:netconf@jabber.ietf.org?join Available Post Session: Recording: https://www.ietf.org/audio/ietf106/ YouTube: https://www.youtube.com/user/ietf/playlists Introduction Chairs (10 minutes) Session Intro & WG Status Tim Carey: Hi, this is Time Carey with Nokia. The UDP-based publication channel for streaming telemetry, do we know what the status of that is? it used to be an adopted draft but I see it fell off. Mahesh Jethanandani: that document, I don't want to say it got unadopted, I think the authors decided to merge that work with multi streams originator and unfortunately we don't have a presentation of the multi streams originators draft in this session. I think we're just looking at one document which is the multi streams originator document Kent Watsen: I wanted to respond to Tim on that last question. The UDP work itself was suspended. The intent is that someone will publish a draft that would be a udp-based "notif" draft for those subscribed notifications work. does that make sense? The multi-stream originator draft is focused on how to send notifications from line cards or satellite systems, and it's not itself regarding UDP in any way. Lou Berger (as chair helper): okay channeling Tim Carey, he says "yes, thanks Kent." Chartered items: Kent Watsen (30 min) Status and Issues on Client-Server Suite of Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-12 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07 https://tools.ietf.org/html/draft-ietf-netconf-keystore-14 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-03 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-16 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-16 https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-16 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-16 --- not chartered, but including in presentation --- https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-05 Regarding new key-format leafs - no questions or comments Regarding parsing algorithms to 3 YANG modules - no comments Regarding IANA templates - Lada Lhotka: there an ongoing discussion regarding my draft in the DNSOP working group, I don't know if that actually it now appeared in in the main idea of mailing list so I guess this is more a netmod thing to consider but you asked how would IANA know when an algorithm should be added. so my question to this question would be how would IANA know that an algorithm should be added to the registry itself, because as soon as this is decided then it should be clear, or at least I hope, to IANA that the yang should be updated, basically at the same time, so I really don't see a big problem with this, the only problem is that may be careless readers of that RFC could take the module contained there as the most recent revision of the registry which needn't be the case, because then the module lives in in under the the IANA care and may have new revisions, but I don't know how to solve this easily because we have we don't have any any formal language for writing the module templates as usage easier so this is really quite a difficult proposition - Kent: thanks, Lada. It makes a perfect sense to me that there would be a registry that multiple RFCs could be feeding into that registry, and when that registry gets updated it would cause a cascading effect, updating the module. That makes sense in theory but I think, for us in particular, that may be challenging, because we're working with different protocols, in particular SSH and TLS, and I imagine there being registries that are around the algorithms used for SSH and its registry is being used for algorithms that it uses around TLS, but we're looking for a registry that's more universally applicable and I don't know if that particular registry exists that could become our challenge - Rob Wilton: Rob Wilton, Cisco, so I definitely think this is something that should be handled by something like an IANA registry I think that's where these need to get to. I think that it that how to update an RFC to add these new protocols and would be a mistake. I thought with the IANA registries there's ones where you could have like experts that were assigned to add values in so it may be that you could assign the yang doctors or NETMOD or something to update that registry if that was an easy way to do it. So maybe there's other ways to solve this problem that involves different human input into updating the registry, but I think we want to somehow get to a solution where it is in IANA, this is my impression. - Kent: okay, and just as you were saying that, Rob, thank you, it occurred to me that what I was just saying about how there's been an association to your specific registries, we could make updates the IANA request could be if those registries are being updated, then please allow them to be a trickle-down update to this other registry which is indirect, it may not be one-to-one, but with a human expert, they could do that translation and make it happen. that's a good idea. - Rob: yeah, makes sense. Regarding determining which algorithms a server supports: - Henk Birkholz: Hi, this is Henk, I think I somehow find myself on this slide. I think is very important to do this, the options you were highlighting, I'm not an expert in this, so probably this group is and I think one will be selected or a set of them. I think this somehow swaps over to truststore, because all these algorithms and the big asymmetric or symmetric or hashing, they will have in the end, the key material used for these algorithms and I think nevertheless that is truststore side, there are hints and methods to find and identify these keys and I think this belongs also here because these have to be defined like in the same way, I assume, with the algorithm there comes an identification for the payload for the algorithm, and I'm probably that is not a part of the keystore, because that is too late, if you go to the keystore you already assume your how to find it, so there has to be a link between the key identification or key hint or identification hint, they love multiple names for this, here on this side of the crypto-types thing, and maybe, I'm wrong, but I just wanted to give this as a comment. - Kent: okay, alright, I'm not sure, it seems like maybe add a second comment, but we respond to the first one. I think what you're just discussing right now, is what I was saying about the need for having the global dictionary, you know what are the algorithms, what are all the typedefs for interoperability. here what we're talking about is trying to identify the subset of those algorithms that a particular server supports, and so I think it's actually but that's a different discussion; and to the first question, what is the global dictionary of algorithms, if you look a little bit deeper, here we're talking about the crypto types draft so there's the universal set of algorithms at that level, but then if you were to look into the current SSH and TLS specific drafts, you'll see that they have mapping tables and, in particular, the SSH and TLS protocols they have very specific algorithms, enumerations, values strings that are sent over the wire, and so there's these mapping tables that, for those who are familiar with ssh specific algorithms or TLS specific algorithms. e.g., be mindful that the algorithm was normally called "foo" in in TLS, its actually you know "bar" in the crypto-types draft, so there's that mapping. - Rob Wilson, Cisco. I think this is part of a generalized problem of basically server capabilities and more I think that we, as a working group, or maybe in NETMOD, need to look at that more about giving devices capabilities and putting instance data file format, and having that avaliable off a box, and that's part of the work that Balázs has been doing, but I don't think we've defined all the capabilities, but I see this ia a subset of those, however that work will take a long time, so I think what we're looking at here is sort of a stop-gap measure, there's no plan-B in the short term and I think that either of what you propose here work, either global list or I think your suggestion of having six lists that seems reasonable to me. I wouldn't go anything more complicated than that though. I'd keep it, I think what you're proposing then makes sense. - Kent: okay great thank you. - Martin via Jabber: Mahesh (as chair): before Robert gets on the mic, we have a question in jabber from Martin asking do we need a similar list for key format supported and supported key format - Kent: there is, but, um, is it possible to go back to slide number five quickly. on slide five, you can see those if-feature statements, the on the symmetric key the asymmetric. one asymmetric key, the those are CMS structures which are more complex, or less common commonly used, than the raw key values. If you were to use OpenSSL and ask it to generate a key, or even OpenSSH and ask it to generate key, neither of those tools are going togenerate the one-asymmetric key structure by default. However, in some cases it's preferred to use those structures because they do two things: they internally embed the algorithm identifier which is somewhat redundant and maybe we should gloss over that fact, because a lot of structures embed values that are also redundantly expressed outside the structure, but more importantly, it's necessary to support attributes. for instance, a private key can be tagged with attributes that it's only to be used for signing or it's only be used for encryption or, you know, the kind of things that, in TLS certificates, might be referred to as "key usage". the one-asymmetric-key structure has the ability to capture the "key usage" where the raw value have no way of doing that. so in some applications, it may be important to use the CMS structure over the raw value, to have that ability to express key-usage, but then lastly it's actually necessary to use these structures, the one-asymmetric-key and the one-symmetric-key structures, if you wish to encrypt the keys. there's no other way, or no standard way, to encrypt or express keys that have been encrypted other than by using these structures. so, in all of that response, what I'm trying to say is I view the use of these structures as sort of advanced. you know the simple "get it to market as quickly as possible" application is unlikely to want to support these advanced structures hence the desire to put them under if-feature statements and, answering your more specific question about should we have config false lists, I don't think we need to have config false lists like the ones that we're talking about for algorithms because we have a feature statements and, you know, a client connects to a server and fetches the yang-library to determine ask what features are supported. that is, in a way, a config false list of those features that have been supported. the only thing that's not really being captured is if it granular enough, as features are a global and maybe yuo what to know for SSH versus TLS specifically, maybe that was your question? - Martin (via Jabber): suppose I support ssh-public key but not subject-public-key-info - Kent: I think Martin I had this very conversation on the list and in the reply to that question I was thinking that there could be "must" statements whereby in the SSH and TLS client/server modules, where these groupings are used, modules where they are using the groupings, they could be refined with a must expression that would restrict each to a specific kind. Makes sense? - Henk: this is Henk at the mic, I no longer have a question but, yes, that makes sense. - Martin (via Jabber) fine with me, less flexibility, but I think that is okay - Kent: alright, if we can jump back to slide 10, or is there another comment about that question? - Rob Wilton, Cisco. going back to the second question I think it's almost the same answer as before that I think we solve this as part of wider capabilities work I think and so I think what you're suggesting are just saying you update the description statements I think that's fine I think that's sufficient for this I wouldn't try and do anything more sophisticated here to keep it simple now and say this could be solved in future, hopefully, if there's interest - Kent: okay great thank you all Regarding raw public keys and pre-shared keys: - Henk: This is Henk at the mic. I think there's a distinguishing feature that we are collapsing, but is not applying to both sides of the coin, which regards key IDs. That is, pre-shared keys have preferred, and even sometimes very strongly recommended way to identify the pre-shared keys, because there can be multiple of them, and that is different to other symmetric keys, so I agree with the notion that apparently pairwise symmetric keys or pre-shared keys, whatever you want to call them, are symmetric, because in the new interpretation of the acronym it literally says pairwise symmetric key and so that's true, but the pre shared key identification and typically you'll go with an ID into the system, we don't have the hash always or something more concrete but at the ID, and there is recomended identity hints for PSK for TLS, and I think these do not apply to all symmetric keys, so how do you deal with these different kind of ideas to collapse the concept and symmetric simply as that - Kent: are these IDs communicated on the wire - Henk: yeah - Kent: what's not being shown on the screen is that each of these lists have a key value, and it's called "name", and it's an arbitrary user specified name, that's how you, but you're referring to a value that needs to be communicated on the wire okay, so that may be a reason for needing to actually you know have a distinct leaf for those values. can we take that up on the list? - Henk: sure - Kent: thank you all Regarding merging ssh host keys and raw public keys: - no comments, but Kent says that that it requires trying it out, and folks can look forward to that discussion later. Regarding RPK & PSK impact on the NC/RC models: - Robert: Rob Wilton, Cisco. I don't know how important this is. If there's a choice and it makes sense, you can defer this, I would suggest it's better to try and defer this and get the drafts finished, so that's my preference. but if this is required for this to work then we need to do it now but I don't know - Kent: within our working group, looking at the NETCONF and RESTCONF protocols, I've never heard anyone ask for this support. the desire for wanting to add support for PSK and RPK, I mean theoretically as possible and it probably should be supported within the fullness of time, but the immediate use [for PSK and RPK] would be more for Henk, as he was the one asking for this [PSK and RPK], it's more for COAP, and and COAP's use DTLS, which is a variant of TLS, and they very much want PKS and RPK for TLS (DTLS), but there's no push for NETCONF / RESTCONF support. I don't think it's necessary, so I'm very happy and willing to defer the definition of these mappings until later. - Robert: yeah, my preference is to defer, and they Henk can write a draft on this. (laugh) - Kent: okay. - Henk: TLS is also using them, not just as often but it's most certainly it in the TLS stack, so if want to be TLS-compliant, well... - Kent: yeah, that's right so there you're right, theoretically, if someone wants to use them, and if we don't do these mapping then they simply can't, unless they create their own, mappings but I think that's okay, I think the working group could decide to just not worry about that into the problem arises completely, so we're aware that there would be a hole in the solution and, with our eyes open, say it's okay. - Martin (from Jabber): two questions: 1) with option 2, doesn't that mean that we have an incomplete solution? 2) can we leave out RPK and PSK from NC and RC? - Kent: yes, exactly. so first, it would be an incomplete solution, as we were just saying and then, secondly, can we leave them out? i think what you're asking is can we somehow make it be that clients cannot use them, I can't respond to that just right now, I mean, can there be a 'must' expression or something like that to restrict the syntax so that it's not possible to configure, I need to look at that just a little bit more Regarding plan to remove local/external flag: - no comments, but it seems that we need to ensure a feature statement is added Regarding required-or-optional flag: - no comment, will remove in next update. Regarding refining cert-to-name mandatory true to false: - no comments (but should add a note that such a list entry should be at the end of the list) Henk Birkholz and Eric Voit (10 mins) Notification Message Headers and Bundles https://tools.ietf.org/html/draft-ietf-netconf-notification-messages-07 Mahesh: As a contributor there is interest in discovering receiver support. But the transport might decide what might be used. ln HTTPS notification case we use OPTIONS to discover a receiver support. The question then is the format. How would the receiver capabilities be documented? When read all the capabilities that the receiver has is discovered. So that's something surely the the draft can take up. Henk: You (?) can come up with capability options and how to maybe fine-grain them maybe not even I don't know but we can work on this for our first draft and then give it to the group and if you can find out of this makes sense Henk: If we are talking about YANG telemetry isn't it more useful if you focus on the binary representation therefore have all the values not in texts but as a binary representation? Our default option is binary and this has to be discussed in the WG. Robert Wilton: I think binary coding is key for telemetry. Even non-IOT devices like routers are generating a lot of data that needs binary encoding and without having support for that I think it acts against the IETF telemetry solution. Henk: I'm in total agreement so thank you. Henk: Sorry, one last question on WG closure. Mahesh: We still have the whole question of receiver support. Let's try to address that before we talk about WGLC. Balazs Lengyel (10 min) YangPush Notification Capabilities https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-05 Rob Wilton: Just a couple of comments. For your NACM node instance identifier there's now that definitions sort of moved into our RFC 6991bis so you could pick it up from there. I wish I had the same definition. I think is what you require but they have dependency on that document I don't know how long it's going to take that would be a better choice if we're willing to wait. Then the other comment I mentioned to you offline is that you go back to original slide, in terms of the selection capabilities you can select a wildcard for interface names but we would have cases where it will be useful to say I want to do these statistics for physical interfaces differently from tunnel interfaces or sub interfaces. At the moment it could be to list every single interface on the device which would be huge and dynamically changing or the the wild-card is i too generic. I'm not sure what the best solution to that is. Maybe we could augment it in with additional filters but I'm not sure where that breaks the logic. Somebody reading reading this document might say they don't understand those XPath filters but maybe we should discuss that further. Balazs: NACM node instance could be taken from rfc6991bis. It would delay this work. I don't know how rfc6991bis progresses. I think we will not be reworking NACM either to use that so I would like like to avoid that. But the main reason is a time and dependency. Regarding more specific filtering, yes that could be done with a simple wild card or define additional filter. We already have subtree and XPath so defining a third kind of filter might be a good idea. Also I think there people are having problems reading XPath filter. XPath filter is very powerful and I'm not sure many people will understand it so I see a risk there. Also then we get into the problem of overlapping XPath filters and how do then we have priority between them and how to handle them. So my preference would be to maybe put that into a bis version of the document, if that's really needed. Robert Wilton: Okay Qin: Follow-up as a global point actually we have relevant draft (?) to discuss how to specify the selection filter. Maybe you have to filter some some useful data you don't need. It is relevant to your work actually. Balazs: Let's discuss it offline. There's one minor point that I have to discuss with Lada about the yang doctor review I think we can take it offline. Mahesh Jethanandani (10 min) An HTTPS-based Transport for Configured Subscriptions https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01 Balazs: I would be interested that if you get these capabilities, that you don't want to get the capabilities for every single HTTP notification. In that case you need to say something about how long do you think that they are still valid or by caching them. Mahesh: This is per receiver? And the second part, your are you contemplating that the capabilities might change in transit. Balazs: No. On Monday I have a notification to send. I discover the capabilities. Will I still assume the same capabilities on Tuesday? Mahesh: Yes. Balazs: Indefinitely? Mahesh: Yes. Balazs: The second comment is about security. I got strong comments from some implementers that if you move the receiver definition outside of the subscription part so the indirection to its own own data model then configuring NACM will be quite tricky. If you have a subscription but someone else is allowed to modify the receiver under your subscription because it's a separate data tree that can be a risk. At least you need to mention this in security consideration. Third that I'm also working on 3GPP and it seems is in a very very strong need of this and urgently. Eric Voit: Question on the capabilities from Balazs, which was is this going to be the same capabilities as available next week last week or whatever and the the goal really would be to have the same kind of capability exposure as we have for the kind of capabilities exchanged when NETCONF or RESTCONF session was established. You find the capabilities out for the server and to have the same life cycle of capabilities that's done with other types of transport establishments. by Balazs: In NETCONF the capabilities are connected to the session lifetime so that's easy but what do we connect the capabilities lifetime here? Eric: I would have expected that we'd get the same kind of a session establishment going on here. That was the assumption. That we do this was part the capabilities exchange for the session. Michael Wang (10 min) Bulk Subscription to YANG Event Notification https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications-00 Balazs: What number of subscriptions did are you assuming? Speaking of five ten hundred thousand notifications that you would bundle? Michael Wang: Yes, maybe multiple streams. We can only use one group ID in the subscription so that we also can receive this state data in only one message. We can help to reduce the interaction between the client and the server. Balazs: I understand that. Just asking what is your assumption? What size of groups would would we be using in the real world? 10 or 10,000? Qin: It depends on the use cases. We want you support multiple streams. You may gather metric from each member and aggregate it into bulk subscription. So the number could be very few. In some cases ten or more than twenty. Rob Wilton: In (slide 4) this case can you also use a sub-tree filter to achieve the same effect. So rather than actually having to have separate subscriptions for the different paths foo bar and baz, could you use a sub-tree filter that would achieve the same thing. You still end up with one subscription and using the sub-tree filter to achieve the same thing. I'm not saying we shouldn't do this but I think we should consider whether this probably could be done using subtree or XPath filter. Qin: In some cases you maybe not be able to correlate the subscriptions. So using sub-tree filter may not work. That's why we introduced a new group ID to help you to correlate different object. In some context you do need to collect a group of data that have common characteristics so you can use kind of group ID Rob Wilton: If that's the case can you give examples in the draft of where existing solutions don't work. That would be helpful. Benoit: (On slide 3) If I understand correctly this is going to be useful where you going to delete all the members of the group in one go. This is the main advantage. Right? Then I'm wondering it this a big enough problem to solve. You have multiple groups of YANG object that you're streaming and you have to delete them one by one. It's because you don't care any longer. So even if you keep receiving some more while you deleting all. I'm not sure the gain is huge to tag this as a group, and to say I want to delete everything from group foo. Michael Wang: There is a need to do everything in one group because you want to subscribe the same characteristic based on your want. Eric Voit: Some of my questions were already hit. One other thing that is not explicit in there is you have one filter as Rob was mentioning and you could probably get away with this with one filter but have you thought about having or what the implications of having different filters might be for that for each individual stream. I think that that's an interesting question because knowing how many how many filters might be interesting and whether the group is actually applicable would be would be something to work through. Martin: The assumption is that it is useful to subscribe with the same filter on many streams. I wonder how common that is this. Michael Wang: If we have some idea to classify different across different group it maybe can help to do some specific application. okay in it so you we are all Mahesh: I think you should take into consideration the comments that you have received. All seem to be around the use case that you have up there which doesn't seem to justify the need to bulk manage a set of subscription. Maybe you need to work on the use case a little bit and come back with a better way (or example) as to a why this is is needed. I think specifically the comment from Martin and Eric on what the filters would look like and how you would might want to group them. Michael Wang: Okay. Tao Ran (10 min) Notification Capabilities Model Extension for self-explanation data Node https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities-00 Balazs: I heard about at least one more draft where we want to define different types of node capabilities or data node capabilities of the server which i think is generally a good idea. But it somehow conflicts with I was instructed by this WG to keep my draft to notification capabilities. Now we are stretching the word notification. I don't know the solution. I think the general idea of providing such information is good but how to handle it. Benoit Claise: I could see some use cases for this. While I wasn't a big fan of the tags for YANG modules I see some value for tagging of data nodes. I believe that if we want to do it right we have to augment Balazs's draft for a notification because that's the right way to do it. We have to observe that this goes way beyond beyond telemetric abilities. But I think that this is a right way to do it. [End of meeting]