Netconf Status PagesNetwork Configuration (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2003-Apr-30 —Chairs:
IETF-105 netconf minutes
Session 2019-07-22 1000-1200: Viger - Audio stream - netconf chatroom
Introduction Chairs (10 minutes) Session Intro & WG Status Balasz Lengyel, Ericsson. I would like to ask what's the situation with some of the other YANG Push related slides. For instance, there was the UDP encoding, there was the binary encoding or unity transport the binary encoding, call home that was provisionally taken out from YANG Push. Kent Watsen: There was a draft called UDP pub/sub, is that the one you're referring to?, that was a working group adopted draft but we unadopted it last time, because the main focus was actually the multi-stream originators. What that draft needs to do is be brought to the workgroups again has a "notif" draft; something like "UDP Notif". If someone can submit it in that fashion then it could be accepted by the working group. Mahesh Jethanandani: makes sense? Sorry could you speak that at the mic? Kent: he says that on the website it is still adopted. Balasz: on the status page UDP Pub Sub is still listed as adopted. Kent: We''l have to take a look at that. We did asked the Secretariat to remove it, but we'll check on it again. *** ACTION: chairs to remove UDP-draft from "tools" page Balazs: and the binary encoding and call home? Kent: the binary encoding... Mahesh: ...is still in individual draft. It is not yet a working group item, if you're referring to the draft that I presented a couple NETCONF meetings ago. Yes, so it's still there, it may need a revision, but it is an individual draft at this point. Balazs: and the call home parts that we took out of YANG Push, is there any development on that? Kent: If you look at the draft that Mahesh is presenting, the last one on the today's agenda, it's actually a "notif" transport for configured subscriptions which does in fact do call home. Actually, we shouldn't say "call home", let's just say "device initiated connection". Balazs: okay. Henk Birkholz: Hi, this is Henk. I will join in Kent's presentation later and, in that context, I want to highlight that there could also be a CoAP call home because in the context they were presented here that so there could be multiple variants off to doing this and I'm not sure if there should be a cross documents or in a single document. I don't know. Kent: what Henk is saying is that that there's another effort for doing a binary transport, a binary "notif" transport for notifications. Chartered items: Kent Watsen (30 min) Status and Issues on Client-Server Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-10 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-05 https://tools.ietf.org/html/draft-ietf-netconf-keystore-12 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-02 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-14 https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-14 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-14 https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-03 [ The following regards "Discussion 1"] Kent: This presentation doesn't discuss the trust anchors draft which Henk and I were discussing yesterday and Henk wanted to ask a question about it, so maybe now would be a good time to ask Henk to ask his question about the trust anchors draft and, especially how relates the TLS draft... Henk: Yeah okay, so this is Henk again so. This is my officially it's a CORE-hat, but it's probably also a YANG of Things hat on. All of these people who try to do binary-yang. There is CoreCONF coming up, formally known as CoMI. This is using DTLS, if it's secured, of course, and it should be, and that will be and in CoAP, and on the DTLS-level, CoAP advises to use different ways to secureCoAP and that is 1) a raw public key, as a minimal CMS frame, as it was standardized years ago, and also 2) we have this concept of pairwise symmetric keys, that are pre-provisioned and both of these are suggested methods to secure CoAP by the CoAP RFC. And they can be applied to two levels they can be applied to DTLS and therefore what extend into TLS which is effectively also done today I mean a lot of people use PSKs, known as "pre-shared keys", we like the term "pairwise symmetric key" and the raw public key of course is a little bit different than the SSH key material, so my proposal here and this mic is to add these two flavors, the raw public key and the pairwise symmetric key, to the trust store draft. Kent and I were already talking about this, so we are aligned, but the room has to be fine with this, because this extends a little bit into TLS and into DTLS as it is mandated by CoAP end. It can be both on the communication layer but also on the object security layer, so it's a communication security and it can also be an object security. so it also goes back to "OSCore" the "object security for constrained environment". So there are multiple consumers of this information and my personal point of view is we should add that to the draft itself. Kent: okay, great, thank you. Actually to add to that, the TLS draft primarily considers certificates, but TLS does support other forms [of credentials] like PGP and and pre-shared keys, and currently the trust anchor draft does not have any support at all for these things. it's really an ommision that we ourselves should have caught before and I would expect IESG would call us on when taking the TLS draft to Last Call. What Henk is raising right now in the context of DTLS is something that we already had an issue with the TLS draft and and thus extending the trust anchors draft to support pre share keys and raw keys, would be the proper thing to do. Tim Carey: Tim Carey, Nokia: I do have a question on this approach though because, you know, there's gonna be many consumers of these particular drafts, hopefully ,right, outside the context of you know just client-server type of stuff, so here we have an example of CoMI and CoAP wanting to augment, and I use that word I think appropriately here, some of the work that's happening in the keystore, you know, from a different area, so is it is it the approach or strategy to continually revising these drafts that is the universal crypto or keystore types that we wanted to deal with, or do we expect the other working groups to use those drafts or incorporate them into their into their work and so I'm just trying to understand the difference because otherwise we'll be revving this thing for every use possible. Mahesh: there is a SecDir review of the set of drafts, sometime later today or maybe tomorrow, and we will be looking for proposals from them to tell us whether the approach that we are taking allows for extensibility, if need be, without necessarily revising these set of drafts continuously so, please, if the framework of these drafts looks good enough, then other working groups can extend the models Henk:This is Henk again and addressing the concern of perpetual churn, we don't want that, so it's basically the same scope, but I think it was like more like an oversight on the on the DTLS part, so we are not not moving outside TLS and SSH here, so the requirements are coming from the same document. We actually have the same scope but we are now completing that scope i think, and beyond that, it should be different drafts or someone else managing us Tim: okay so what I understand what you're saying, Henk, is is that the that the base, what we would consider to be any base draft that would come out of NETCONF, will incorporate both SSH TLS and DTLS and then we kind of missed the DTLS, and that we are agreeing as a working group that DTLS is a core secure transport for the work that we do, right? Kent: i don't know which hat i'm using at the moment, but this working group is primarily focused on NETCONF and RESTCONF, and they only have SSH and TLS as official transport bindings not yet, sorry Henk, and that's why I mentioned before that even TLS itself has already the need to support pre-shared keys and raw-keys, it's in the TLS draft, so our support of TLS for our own purposes is already incomplete and that's what I'm saying Tim: so you're saying that it's not a DTLS thing Ken: Correct, what we have already is incomplete. Henk raised it, and he absolutely correct, it would have been caught by IESG had we tried to take the Last Call, but it's better this way that we can while we're the focuses on trust anchor getting to Last Call Tim: but we would expect CORE to take if they want to use this for detail us we would do anything different, right, we would expect CORE to take it Kent: after trust-anchors has been published, if any other group wanted to extend it and add another kind of trust anchor, then it would be another draft defining YANG augmentation and it would proceed that way Heck: basically, this is luckily coincidence that this is not exceeding your scope Tim: okay good *** ACTION: authors to extend trust-anchors draft to include support for pre-shared keys (pairwise symmetric key) and raw keys to trust-anchors draft. Kent: (regarding the IESG meeting on Sunday) Ignas, did you want to say something about that? Ignas Bagdona (NETCONF AD): yes, this was discussed briefly at IESG Sunday meeting and the outcome of that is that there is no outcome at this time right and what is needed is that probably this working group needs to think of what are the proposed options? Either we don't have a registry but put a hardcoded values into into the documents and we spin that every time, or have a unified registry which is on the IANA side, or have something in between? this is something for probably NETCONF here to think about that and provide a recommendation what you would see, what would be more stable in the longer term. *** ACTION: chairs to ensure working group considers options for crypto-types solutions Kent: (regarding the posibility of leveraging COSE's work) Henk, did you want to speak to that? Henk: This is Henk again. It is for COSI, for the CBOR variation, but Jim Shot (sp?) is the expert on this registrybut all the participants there in the group did an awesome job. it's key-pair parameters, its curves, its hashing, its signatures, its crypto and it's always in combination that are safe, withf key strengths and so on. It's very elaborate IANA registry already there, it's pretty much, I don't want to like to say complete, but it's very very detailed already, so this could be another well-maintained source for everything crypto. I'm not saying that is complete for your scope because, it prunes some of the very old stuff and of course of the deprecated things, but it's the best maintained IANA table I know, so maybe yeah. Frank: Frank Xia(ling), Huawei, I have interest and general question about this kind of thing. thank you that you have mentioned that for the COSI, for this technology, we have a very complete crypto algorithm on the IANA page, right?, so what is the relation with this new IANA page and the with the existing IANA pages for TLS, IPSec, and SSH? and what is your future plan of how to align with them, and you know this is a very important the problem Henk: yes, this is Henk again, this is not resolved yet, so we have either the option to choose in the module where to go to but this can be very confusing and it would require a lot of implementation and complexity, so that's usually a bad idea, but if they're gaps and if you see, maybe an assessment of the tables is an order, but you're TLS-based so that's a way to go, you cannot do something wrong there, I think. From the YANG of Things point of view, we could just document that and have an extension point that there is good to augment, so the YANG of Things realm could do that just and live with that, and that's okay. I just wanted to highlight that there's another table, it's well maintained, and it goes beyond what TLS does, but it might not be complete because I have not made a one-to-one comparison of those, actually, this is just the first discussion about this. Frank: my personal comments is that it's not the responsibility of the individual or group charter to maintain or reflect the latest update of crypto algorthms. I hope that those IANA pages can, you know, can be aligned with each other, and they (IANA) take care of this kind of thing and we just reference to them. I think that's the best way, for not only for our draft, but also for future another draft, right, IANA should take care of that module or this kind of thing. Kent: okay great, you're right, this is definitely a good resource for us to look at and in terms of potentially folding some of those ideas into what we're trying to achieve with this approach. *** ACTION: authors to consider the COSI registries maintained by IANA Rob: Rob Wilton, Cisco. Why would you spit it in many IANA modules something missing that step as to why it goes from one to many Kent: that is the second bullet point so, again, as unclear to me how important it may be to me, fomr a programmatic perspective it doesn't matter, but from a maintenance perspective, especially for asking IANA to do the maintenance, it could be helpful to them that then it's been broken up too many modules. In either case, it'd still be one draft, this crypto type draft would continue to be the draft, but would instead create all these modules,if there were many modules, it'd still be one draft that defined all the modules and assign them to the IANA Rob: so those modules, are they are they representing what the different security working groups are producing Kent: exactly, for instance, there would be a module that be for symmetric key algorithms, another module for asymmetric key algorithms, another module for hashing algorithms, if it makes sense to break up that way *** ACTION: authors to consider fallback strategy [ The following regards "Discussion 2"] Rob: Rob Wilton, Cisco. Is it safe to have a single operator wide symmetric-key. I mean, is that good security practice, in the sense of, if that key gets compromised, do you then effectively compromise all the devices and, if so, with these schemes to work if rather having a single operator wide symmetric key they were managing separate keys for each device so, when you RMA it, you use what keys it has Kent: sure you're right it could be the case that it's a per device symmetric key, not operator wide. You're right that its just more maintenance, the operator has to remember what was the symmetric key used before for each device, but it could be done. Rob: that's their choice Kent: that's their choice, specifically, the crypto officer's choice. We push the problem to them, one solution would be a per device symmetric key, another solution might be to design some code around a symmetric key stored inside a TPM of some sort, and then they develop a client that basically does a handshake transferring this symmetric key to the new device in a way that in was never revealed to the crypto officer what that symmetric key value was. That's also possible Rob: okay. I think having some Security Considerations of this and speaking of security people about whether this works would be good. *** ACTION: authors to add additional information to the Security Considerations section. Rob: one other question I have on the bottom on you so you so you modify the old device to remove the old operator wide key. why is it better to do that versus another way? Kent: remember, the first bullet point was saying to go to the new device and load a new operator wide key, the second thing is if, and maybe this is out of order, but the second thing I'm thinking if you load that configuration from the old device and it has a new definition for an operator white key that would overwrite the value that you just stored, so it you're kind of like avoiding that overwrite, so maybe just change the order this, load the old config and then manually overwrite the old operator Rob: or another way expressing this would be to say when you write that old configuration, you need to strip out the old device key Kent: or replace it Rob: yes Kent: with a new one Rob: yeah Kent: there's different ways of saying this, but the intention is that it's the same symmetric key, it's just encrypted with a different public key, because it's a different device and your device has a different, it's actually the same symmetric key value, just encrypted differently, so the config is slightly different for that reason. Rob: okay Frank: I just want to know, how these symmetric keys used Kent: the symmetric key is actually currently only being used for this purpose, for encrypting other keys. in fact, the data model up until the very most recent version of the draft did not have this symmetric key section. There were no symmetric keys being stored in the keystore, the reason being that it'd be foolish to have the symmetric key value in the configuration where anybody could see it, all security properties would be lost, but now that we have the ability to encrypt the symmetric key then it opens up the possibility that the symmetric key can be stored safely, so that's one, and then, two, we can then use it to encrypt all those other keys that are being for instance used by SSH, TLS, etc. So that's how it's really being used currently but, to Henk's previous comment about extending the TLS support and truststore to also support pre-shared and raw keys, I would like to have those keys also be encrypted with the symmetric key so that would be another use that I'd be thinking about Rob: yes, can you go back to open issue one, so now for this one, your point at bottom, the cons, that it might be better to define an annotation to mark this configurations read-only, the status read-only, so the factory default datastore is already read-only, by definition, and running is controlled by the client, so I didn't get that bit, what you mark as read-only? Kent: I'm sorry, what is the question? Rob: so the annotation, is you suggesting I have me an annotation to mark something as read-only Kent: yes Rob: but in factory default, already everything is read-only, same in operational Kent: right Rob: so what's your what's the annotation annotating Kent: oh okay what's the anotation doing? Rob: yes Kent: okay, remember factory default is kind of like startup, where it really is it's a place where you copy and and you initialize Rob: right Kent: it's the first , effectively, it becomes and then, you're doing a on and that's when it would be helpful for some people to know that some nodes are actually read-only value, kind of like with-defaults you're being told this is actually a default value Rob: okay, so you say effective you try to write to one of those values in , the device would reject Kent: that's the intention, yes Rob: yeah, I'm not sure I like that Kent: okay. We can hard code it for this draft and not create the annotation, but I think there's an opportunity to create an annotation that could be extended to be used in other use cases as well, we don't have to hre, I'm just opening under so possibility, let's take an online. *** ACTION: authors to take annotation idea to list. Mahesh: we have a comment on jabber from Henk saying "yes, providing confidentiality to key material should include all key material" Kent: okay Balazs: Balasz, Ericcson. This annotation could be very useful for server capabilities somes times, where you can't change them because the capability is read-only, but you want to reference them, for example in 'must' or 'leafref' statements Kent: okay Rob: Rob Wiilton, but then I question whether they're running configuration, I think capabilities still needs to be solved, but I'm not sure that's configuration. They are not coming from the operator. Kent: well but I think what Balazs the saying is like, when I2RS did the topology drafts and, the topology was being discovered through the data plane and populating operational, but then they wanted to have configuration that would extend it in parts of the topology that was discovered, they needed to promote the values to configuration. We told them at the time was okay to copy those nodes from and put them into and the intention is that when it got committed, that the device would know that this is something that is already in and hence doesn't need to be created again. But, to Balázs's point, it be actually helpful if they could be tagged, a bit like with 'origin' tagged as to know this is actually a value that came from or this is actually a value that is read-only Balazs: exactly I don't care if we called it or not , it's a value that was discovered from somewhere, in capabilities cases probably from the software itself, and then I can puta 'must' statement indicating that some configuration is dependent on the device being capable of supporting some capablity. Currently, you can't put a 'must' between "config false" and "config true", this is the way around that. Rob: Rob Wilton, Cisco. So I wondered in that case whether you want to be getting that configuration to , so in you I have more freedom to be allowed to inject system-configuration and templates and things. There is more freedom there, and that's where you're doing the validation, so still see that the ideal for is it's just what the operator provides, so they say, this is the config file for what that device should be doing, and they have complete control over that and then you merge it with which is where I see these sort of default keys coming in, validation all works because it's actually effectively that's validated and is implicitly valid by the fact that is, but not updating Kent: hmm okay so let's flesh they're on the list, again, this is an open issue so it needs to be discussed on the list and it I hope to see you responding there Rob: yeah [ The following regards "Discussion 3"] Rob: I think that if the authors think that it should be done then I would do it Kent: perfect *** ACTION: authors to decide if to propogate the restructuring from restconf-server module to the other three modules. Kent: ok, so that's it, thank you for the input. Mahesh: so just quickly summarize the next steps that you have planned for the summary of drafts. I know one of them is the definition of whether we want to go to the IANA registry, what format should look like anything else Kent: I always feel guilty answering this question. Every IETF, it comes up and, of course, the pressure is to say you know we'll get it into Last Call in two weeks time, and then it slides. The reality is as I just mentioned crypto-types traps is we're having SecDir review. It needs to go to IANA. There needs to be a discussion if we can do the right thing or if we need to do a fallback thing, how long will that take to play out, I don't know but it is the dependency of everything, everything depends on it. It's also the long pole in the tent. Then there's the trust-anchors draft, which I thought was done, but Henk just mentioned that there's a desire to extend it to support preshared-keys and raw-keys, and we need it, it was an oversight we should have done it, we'll add it it's a little bit more work, but I think it'll take less time than it will take to get the crypto types thing to resolve. And then, lastly, keystore, which I just presented, I think we're done there's a couple points about open issues, one and two, which we need to resolve, but they look relatively minor, and definitely should resolve sooner than the crypto types so, ultimately, it comes down to how long will it take to get crypto-types draft done, and I don't have an answer for that. Mahesh: does anyone have more questions. Kent: I don't have any more questions Mahesh: thank you. Balazs Lengyel (10 min) YangPush Notification Capabilities https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-01 Benoit Claise, Cisco. so actually I like very much on-change flexibility. For example we could have on-change on the entire datastore or we could have on-change for specific feature. For example the question is not how complex you want to have it, the question is how reliable we want to get this contract with the box. If I go on a box where the minimum of that period is for entire datastore, great, but there are some other where the cadence that you want to get information on is different on a line card for example for a specific interface. We want to get the contract whenever you connect to a box to understand the minimum of the period for each of the different things you can get. In the contract and we connected to it tells me for this part of the three I could get you every half a second but for the other one interface counters on their line card on this big box I could do 30 seconds. I get it that it might be complex but we might be getting the same flexibility that we've got below or at top as well. Balasz: I see it as somewhat different because these global minimums are saying that the best the box can do in any part of the data model any datastore is, I don't know 170 seconds, and then you try that for interface, oh, interface sends you back only at 2 seconds. You still have that reliability. It's one more round trip you can put it in the date. These minimums mean that that's the best the box can ever give you. Maybe some parts will give you a worse value. Benoit: Maybe it's not the right question to ask what is the best that box can do. I want to get like my FIB information every 10 centiseconds or whatever is the minimum the box advertises. The box then replides , no Mr. Customer, it's common sense to get it every 5 seconds. It is a question of consequence and setting the right expectations or to rely on the information. Reshad, Cisco: Just to add to what Benoit was saying, in terms of implementation you have collectors and sensors with different hardware and have very different collection capabilities. You already have fields per sensor path and it's not like you're adding an extra list. If you put the update period per path, and it could be optional by default then there's some significant benefit. Balasz: I can live with changing the model. Robert Wilton, Cisco: I have not read the latest version the draft. I have two questions though. One is this information available offline? Is it like instance data? Balasz: This is a yang model and I very much hope that instance data will be provided but that's really up to the vendor to decide Robert: The second question is in terms of these paths if you have a device that supports many interfaces, can you wild-card those paths to say the counters under an interface on any of these types of interfaces will have the same performance, without having to list every single interface? Balasz: At this point I'm using node selector from an ACM which might be moved to use the YANG types that say it's the format is the instance identifier but you can omit the keys, meaning then it is every key value. If you want to go into more specific Ethernet interfaces or fast Ethernet interfaces then you have to do that one by one. Robert: Okay. Balasz: I don't think we want to have a full regular expression language embedded here. Robert: No and I agree and I think that's probably right compromise. But it goes back to what Benoit was saying, is that ultimately this is a contract. I think contracts of what's the minimum capabilities you're willing support rather than necessary the maximum. So if you say I can support a damping period of five seconds or with me then you should effectively be able to honor that for everything. Balasz: On-change means I really promise to support it. But these periods either global, or if we put them per datastore, that node or pair, you might still have a CPU overload. I don't think they can ever be taken as a guaranteed time. Robert: Would you reject that subscription if it came in and you couldn't honor it? Balasz: I think the subscribe notification drafts says you reject it and say that try with the double the time or whatever time. Robert: Okay. Balasz: But not less. Benoit: I want to come back to what you said if you can't guarantee the minimum of the period ... There are multiple ways that you could do telemetry. The point is that we should do the best that we can for a device is healthy. If the device is not healthy because it's CPU is overloaded etc. ... The point is that I connect to a box and have a contract. I understand that you want to do this for two different use cases, implementation time and run time. I care about the run time at discovery. Balasz: I would change the model by putting all these values under the lists. It will need to be renamed in that case. still I think that it's not. But the device still has the right to say that I can support on the double time. Benoit: Thank you. Balasz: That means that on-change capable nodes list you have to be renamed to datastore subscription capability or something like that and all these update periods max objects and minimum damping period will go under that list. Mahesh: About last call, looks like you need to make some changes first. Balasz: Yes, this model needs update,but after that I hope it can go to last call. Kent: Just get a sense from the room - How many people have read this version of the documemt? Raise your hand. A few, and there's no really follow-up question. We are not going to do a last call at this time. ***ACTION: Author(s) to update the draft/model based on the comments received. Non-Chartered items: Tianran Zhou (10 min) Subscription to Multiple Stream Originators https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-06 Kent: By channels do you mean line cards? Tianran: Yes, each card will have a channel. Tim Carey, Nokia: We did have a question and I think I brought it up the last time. The question was again about the IOT use case and my concern was that outside of a closed ecosystem, a network element itself would have to have some additional capabilities in place to to be able to discover the capabilities of the network element. So if you tried to extend this to anything outside of closed ecosystem I think there's some considerations that need to happen for the solution to work correctly and all the security that goes around it. Right now you're just constrained to a locked box. If you look the extended past that then you got to worry about discovery and other elements. That would be my concern with the IOT use case. Tianran: What's your suggestion so you think we should not include that's in the chapter or ...? Tim: If you want to go into those other use cases you're going to have to address these different issues and so I don't think that that was your original intent with this draft. You're just trying to say look I've got a I've got a closed ecosystem that I'm gonna put together a master publisher that's gonna kind of coordinate that stuff instead of having different streams. That's effectively what this was doing right and so I would keep it into the context that was in if you do choose to make it broader then you're gonna have to address these other issues. Tianran: Okay, thanks. Kent: As a contributor my takeaway from that would be at a minimum the draft needs to have a section that speaks to this and at least identifies that intention and then there's question of whether or not the draft actually solves it. So one potential solution might be for it to define in config policy an operational state that lists out the channels that the device is having available that subscriptions can be made on. That would be one way to solve it. Another might be to look to the equivalent of an entity MIB where you can somehow discover the line cards that existing on the device and then derive from that what might be suitable for using as channels destinations. In either case, I think, this draft needs to talk to it and and choose an approach. Either say that it's out of scope and and you know it's only going to support closed ecosystems as Tim suggested, or it's in scope and point to a solution that people can use. Guangying from a Huawei, I just wanted to menton that we have already implemented this in one of our machines. Kent: As a contributor, I think we discussed this on lists and the with the channels it was unclear to me that the channels was a lists of channels or .. We don't have a YANG model that is yet defining this this node or this container called a channel or actually is a list. Presumably it should be in this draft. Well actually it should be in the SUBSCRIBED notification draft Tianran: It is not included in the in the YANG model in the draft but if we can agree then I would like to add a channel list under the receiver. That means that each receiver can have several channel configurations. Kent: Again as a contributor and also as co-author of the HTTP notif draft that Mahesh will present after your presentation, that HTTP notif draft is the first notif draft that we have that this working group has produced for a configured subscription and the approach it is taking which is in fact was sort of you know suggested or we're almost mandated by these subscribed notifications draft or what are now almost RFCs are almost first was to augment the receiver nide and so that's what that draft does. It augments the receiver node and then what you're suggesting is that there'd be a channel that's underneath the receiver and that it should actually be augmenting the channel node. So how does is it it know am I supposed to be augmenting the receiver note or am I supposed to be augmenting the channel. The intention the notif draft is kind of somewhat independent of the transport and as such out of the context. How would it know if this is a device that has linecard or not and what is the appropriate augmentation point. I think that's the issue with this draft. I think what I understood and just sort of restate it what you're saying is that the HTTP notif draft could actually have two augments,one to receiver and the other one to channel and each of those arguments could be with a feature statement so that you know it's only one or the other or maybe both I don't know. Or I think, Tianran: No need to do that because the channel configuration is also under the receiver, so you augment your configurations to the receiver of the subscribed notifications draft. Kent: But the subscribed notification draft doesn't itself have a channels list and so devices that only implement that RFC will not be having channels Tianran: I realized this. I send a email to you to suggest to your transport document include these channel configurations so that it can be compatible if you only enable one channel or multiple channels. Kent: There can be many notif transports that are defined. The HTTP notif is just one of many possible. I don't think we want each of those notif transports to themselves happen to be augmenting it and optionally implemented channel. That's is not the right place to do it. I think that you guys can have a data model that augments the receiver lists adding in a channel list. ome devices will implement it others won't . The notif draft could actually have it that they have a dependency both to subscribed notifications as well as to your draft with two arguments and there's a feature effectively that the server chooses whether or not to be augmenting one of the sub channel list if it exists or not. If we move the channel list into the HTML notif draftand it's only one of many possible notif ... that it's not the right location for it. Balasz: Ericsson. I'm confused by a statement on this list all potential channels are pre-configured so others this configuration data config true nodes, Tianran: Yes it is configuration. Balasz: How do you prevent the user to add or remove channels that actually exist or are dummy? We have that problem in many places and have a Ericsson specific or 3gpp specific solution, but what is your proposal? Tianran: I actually do not realize your problem.s Balasz: I see that all channels are pre-configure. But what prevents the operator from going on and saying that there's also Balázs channel. Actually there's no such thing but it looks like from now on as if it was there. So how can you prevent someone messing up this pre-configured set of channels. Kent: There's two things. There's the adding of channels to don't exist and there's the forgetting to configure channels that do exist or removing channels that were pre-configured. Mahesh: We have a comment on jabber from Eric . He says I support Ken's proposal for multi-stream originators. Note, you can augment subscribe notifications or some objects and multi stream multiple line cuts are needed Kent: Let's take a step back. Why do we want to have it list the channels at all? The reason why is because some protocols require her channel configuration per instance and actually it's questionable. For instance in TCP you may want to specify the source IP address on a per line basis. Also for TLS you may want to specify the cryptographic credentials on per line card basis. But those are TCP and TLS specifics. Not all notifications transports will necessarily have either or any such considerations. For instance a flat UDP let's say syslog or UDP has none of these concerns and so a global configuration of syslog over UDP be for just going to receiver you, augmenting receiver and then there could be a global flag that says I want these line cards to be able to send syslog over UDPstraight out the data plane and that's it we're done. It's just a global flag there's no need or a per line card configuration of any sort. Mahesh: In the interest of trying to move this draft forward one conversation that the chairs were having was to figure out maybe we need to put a design team that might be helpful for the authors and if such a design team would be formed if people here would be interested in and of contributing to that design team. Identify the problem, maybe define the scope of the draft and help to move it forward that would be one way we would suggest how you move forward. Tianran: A design team is very welcome Kent: To be clear the work group very much wants to adopt the draft and we think it's important work. I shouldn't say the work group. I can't speak for the group. So would anybody be willing or to work with the author on a design team. I see some hands so that's great and you everyone in the room who raised their hands can send a message to the author so they can sync up. ***ACTIONS: Authors to work with members of the design team to clearly identify the problem statement and the scope of the draft. Mahesh Jethanandani (10 min) An HTTPS-based Transport for Configured Subscriptions https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00 Reshad: Cisco. Why is it called HTTPS and not RESTCONF? Is that deliberate or ... ? Mahesh: t is HTTPs and it doesn't have the heavy load of supporting RESTCONF. Rob Wilton: Cisco any thought to using binary coding here. Mahesh: Good question yes I guess there was that draft presented early on and COAP is also suggesting a binary based notification. So that's certainly something we could consider. Kent: As a contributor this draft actually supports both JSON and XML and the way it does so is through this subscribed notifications draft. Inside that draft'sdata model there's a leaf called encoding-identity with types XML JSON. In theory it could be extended to support binary. Ignas Bagdonas: So again serious question is the working group sees this as the work that is needed if the community would eventually see this being deployed and used. Can I see a show of hands. A few. Who has read this document. All right. I think this needs to be raised into the mailing list about adoption please read the document and please provide your comments and feedback. From those hands it's a little bit premature to ask this question right now and here, so let's take this to the mailing list Reshad: I have read the draft in detail and it's well written, and it matches well with subscribed notifications draft and all that so it's all good. But one thing I was asking the restaurant question before is we don't actually have an HTTPS draft for dynamic subscriptions. We have NETCONF and RESTCONF, so is it just for configured subscription or is there something else for dynamic subscriptions. That's the part I'm struggling with. Kent: So first I'll thank you Ignas for running these question. We'll take it to mailing list. Aand then back to Reshad about question which you raised before. With a contributor hat on. Over the course of several IETFs we did raise and talk about this discussion and certainly dynamic subscriptions have to be RESTCONF and NETCONF because you're coming in over a RESTCONF or NETCONF connection to begin with. With configured descriptions is it the best choice like if the device is going to proactively initiate a connection to a receiver would that should that connection be of RESTCONF connection which all that into it entails.Meaning it's a full connection with configuration and operational datastore etc type connection. Do we want all that or we were looking for something smaller, simpler. Remember this is being implemented on linecards so it has to be simple and people talk about pushing notifications - syslog, SNMP is sort of the baseline for what we're doing. The next simplest thing that we're thinking is HTTPS because it is fairly simple protocol and and it doesn't come with it any of the extra management overhead of RESTCONF. Balasz: 3GPP has recently started defining yang solution set for number of OAM issues and they actually stated that they prefer a configured way of subscription. So I see this is important. ***ACTIONS: Bring adoption call to the mailing list.