Introduction Chairs (10 minutes) Session Intro & WG Status Chartered items: Kent Watsen (15 min) Status and Issues on Client-Server Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-05 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-03 https://tools.ietf.org/html/draft-ietf-netconf-keystore-08 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-11 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-10 https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-10 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-10 https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 Lada: Lada Lhotka. I have a question related to the recent discussion about the deprecated status. So, what's gonna happen if that's a cryptographic algorithm is compromised. What is the supposed sequence of events after that in terms of updating the modules? Kent Watsen: Where did we land on that it is the status statement Lada: Yes, it is currently that the algorithm is not recommended to be used after that, so I believe that the yang module should somehow also take this into account. Kent: right but I'm asking is syntactically can we put the status statement as a sub-statement to the identities Lada: what's probably going to happen in an IANA registry in the corresponding in our history is that this algorithm will be labeled as deprecated in IANA terms, but since apparently deprecated means something else in in in the YANG, this could be a problem I believe, because currently the discussion was the deprecated items basically must be must be implemented anyways. Kent: right now the draft would be published with status "current" and then when IANA deprecates an algorithm, we would have to republish the module with status "deprecated"... Lada: but my point is that it really doesn't work the way that's probably expected... Kent: there is a mismatch in semantics of what "deprecate" means, but I think that we would move forward with calling it "deprecate", because of the YANG versioning rules that we're adopting, and then we could then do a subsequent update to move it to obsolete, to match the full definition of IANA and, in the interim, implementations could do a deviation module to say that they... Lada: you cannot deviate and identity, that's another problem of course Kent cannot deviate identity, okay, I don't think we have that as a YANG Next issue [NOTE: YANG Next issue #40, and now #80] Lada: we can discuss it during the discussion of that issue we have, but I think it's especially important for these kinds of things Martin: Martin Buckland. about not being able to deviate an identity I mean, you don't have to implement all identities in a module, right, and we have an issue with that, how do you actually tell the client which identities you have implemented, and that's that is a YANG Next issue, so I think that part is being covered [NOTE: the idea is that server could implement the module and then deviate away all the identities not implemented] Kent: okay Martin: and also we're talking about going directly to obsolete, maybe in this case where it would make sense to go directly to obsolete. Lada: actually the program is not only about identities, which may be solved in a way that Martin mentioned, but some such types can be defined as enumerations and, in this case, this is clear that it can't work in the same way as for identities Frank: Hi, Frank Xia, Hauwei, I'm also a co-author of the crypto-type document, so I'm trying to answer this gentleman's question. actually, when we updated this document we have considered that, of course, the crypto evidence where we develop and some of them will be depreciated so, what we covered, or what we have written the in this crypto-types documents, we can guarantee that they are the most widely used and most robust algorithms we listed there. we don't include some deprecated algorithms, such as md5, that's our promise, but we also notice that, with the time go on, yes, some of the algorithm we will be older and we have not be safe, so maybe we can updated based on the YANG version mechanism to to solve this problem. I hope we have answered your question. Balazs: Balazs, Ericsson. I have a question to a previous slide, that you want to introduce two new drafts, I'm not against these drafts, but I would be very unhappy if that would delay the base drafts, which are very much needed urgently. Will it delay? Kent: the two new drafts are covered in second discussion. We're right now on the first discussion, can you hold that comment till then? Kent: going back to the questions on the screen, is there any suggestion for regarding the classification of the number of base identities that are currently being defined? are they sufficient. or should there be more or less? so far I've not heard any responses to that particular question yet (no response) Kent: okay, well, as a contributor I I find them to be sufficient, they are currently being used by a number of the SSH/TLS models, which was and is our driving motivitation for crypto-types. We need to ensure that work gets completed and, so long as that's done, then from our own consumption perspective, they would be sufficient. We, the chairs, will ask for early SecDir review of this draft since is so heavily enthralled in Security concerns, so we'll also that review from Security Directorate. Regarding slide #11 (The Bad, regarding "demux containers"), Kent asks if there are any comments. There were none, so Kent said "okay, I'll take that one to the list" Regarding slide #12 (The Ugly, re: using "has-a" for the NC/RC drafts), Kent asks what folks would like to see... Tim: Tim Carrie, Nokia. I think there's some value to this, particularly when we talk about proxies, like if I had a proxy between you know the example would be a proxy between a RESTCONF and a NETCONF. I think there's some there's some usage here that that probably would make sense that we could incorporate Kent: with proxy, when you said that, I'm thinking HTTP Proxy. No, well, inside the (while you're stepping back to microphone) inside the HTTP client model in fact there is a configurable parameter for a proxy, so if your HTTP client wants to connect directly at the endpoint or via proxy... Tim: no, I was referring to an application layer gateway between a NETCONF and and RESTCONF Kent: okay, great, thanks Mahesh: before moving to discussion #3, the question for the working group is that I think in 103, there was kind of a poll taken to figure out if there was interest in working group to adding two more drafts into the stack of drafts that you have specifically to address the question of TCP and HTTP so keepalives. yeah, thank so the question for the working group, is there enough interest in the working group to maybe start an adoption call for those two particular drafts that are not workgroup items as yet a show of hands if you are if you feel that there is enough interest in the working group or if you think there's that you would want to see that work done in the working group (no hands). all right Kent: same question was asked in 103 and there's large consensus the room that they wanted to go this approach Mahesh: so maybe specifically asking believe wanted a problem of TCP keepalive to be resolved using these two drives? okay, if there is no support for it, is any objection, all right no objection either, I guess then we'll have to go back to 103 and also of course you have to anyway formally do this on the mailing list so we can try to send the poll out and see if there's any support. Kent: did anybody read the drafts, the TCP and HTTP drafts? Mahesh: actually, that's true, that's the first question, that should have been the first question. yes no one read it all right so Kent: we're gonna have to take that list but, nonetheless, in 103, there's the it was support given there and this is just fulfilling that the promise or agreement we made before Wolfgang: Wolfgang Riedel. One question so we see in the web scale, we got option of going towards QUIC, so do we have anything any thoughts about maybe moving also in the direction of QUIC and we will combine all the benefits of getting QUIC, in terms of Security, round-trip times, whatever, or is it so I'm just asking if there are any thoughts around QUIC using this in this context? Kent: there's nothing explicit, but I'd be very open to understanding what how it might change. Currently, there's a variation of HTTP and so it seems that we could parameterize the HTTP model. We need to think about that, please send a message to the list so we can take it up there, okay, great, thank you. Regarding #1 (redundant config, need TBD templating mechanism), Kent asks if there are any comments. (there were none, proposal to "do nothing" adopted). Regarding #2 (Keepalive MAY be present for periodic connections), Kent asks if any concerns with using a 'must' expression. (there were none, but not that it came up on the list after 104) Regarding #3 (are the various keepalive models correct?) - Tim Carrie, Nokia, No we hadn't had a chance to look at them yet but we will because I think they're looking at instead of augmenting the keepalives to actually use the draft now so if you remember we had some augmentations in there before in the BBF, they know, they just haven't haven't looked at all that keepalive yet to give you responses - Kent, okay okay good (look forward to a response) Regarding #4 (any desire for other protocol-specific config?) [no comments] Regarding #5 (Not all HTTP auth schemes are defined) [no comments] Regarding #6 (Why have special breakout groupings?) [per on-list discussion, we're removing them] Regarding #7 (obsolete references)