 Okay, so this is an advertisement for a document that I'm partly working on, and this is a document that's trying to document what is required to have a validator do his job, not to document what validators do, because that's all over the place. And frankly, one of the reasons why I'm bringing this up is that the authors, we've been working on this document slowly, you'll see, there's a little bit of history in there, but we amongst ourselves don't have total agreement with what needs to be in the document, and so we're trying to get the input from those so that document will impact, which are the operators and the implementers, so that's the main reason why I'm bringing this up here. So this is, I'm not just trying to say, come to the IETF and comment on the draft, I'll get into that, but we really want to have some input for this document out here, and the title of it is IETF Style Draft, MGLT, DNSOP, DNSSEC Validator Requirements, and 07 is the latest version of it. Now, the reason for this, bringing this up there, there are a bunch of topics in here that we really, we need to get a broader set of input on. I think we have some disagreement internally about what should be said. Now the history of the document, it's been around for a long time, which is usually the wine of many documents in the IETF. I look back to see, I was added as an author at some point, and I was added as an author in March of 2017, which is months after I decided I'd never go into the IETF again. It was kind of odd to be talking about, I didn't have a draft when I said I'm not going to go there anymore. So I've not actually been to the IETF since this document's had my name on it. I do the document from the other author, who's been pushing this a bit more actively, hasn't quite gotten this to be a DNSOP, a DNS Operations Working Group document, an officially blessed document, but it's kind of been on the edges of interest out there. And again, the reason why it's kind of stalled is that I think the document really needs to have a better audience or better input into what goes in there. Obviously, that's why a document exists. So this may or may not be a good document. I think we need to find out, the authors need to find out whether it's worth pursuing this or not. Take a plea here to have people take a look at what's in this. And inside the draft we have these five topics that I'll go through one by one and talk about kind of what's in the draft. But these are things we see are externalities, external pieces to the validation process. It's very tempting at times to talk about how to validate data. We don't want to do that. That's elsewhere. There's already a defined process. But when it comes time to writing the software that do the validation, you just have to live inside of. Number one topic, the lead topic there is time. DNSSEC requires wall clock time. The R or SIGs have times in there. That was there because we don't want to have replay attacks so that signatures can't last forever. Otherwise what you say today will be good forever no matter what you do. So it was interesting to me that this was actually one of the first topics in the draft that not every device out there does NTP. I just assume that being that I usually work in those kind of systems. But all these other systems out there do validation will have to deal with the fact that they don't know what time it is. But they need to do that for validation. It's got to be in there somewhere. The second part, this part was the part that drew me in. And it has to do with the trust anchors. There's a KSK rollover. We're always going to talk about part of that next. In going through the process of the trust anchor or the KSK rollover for ICANN, we're going to think about what is in validators. What is a trust anchor? It's essentially like a data store or database or data structure. It's a data piece. It's configuration data. And it needs to be managed appropriately. And some of the tools out there really had to up the visibility of what's in that data for operators to be able to play on the KSK rollover. So I was interested in getting that document to make sure we understood that it's much a small database, a very small database, but it needs all the ways of inspecting it and changing it. One of the topics I find more controversial is the idea of what do you do when a key is kind of revoked. Not revoked in the sense that we're pulling the key out, but you find that a key has been found to be bad. It was a bad key. Someone else put the key in instead of the real owner or something's gone wrong and they want to pull the key back out. In the draft, it talks about being able to go into the cache, identifying all the data that was validated by that key and marking it as bad data. I'm a little skeptical that that's workable because I know that we've talked about that for years in the implementations of DNSSEC. But again, this is something I think we need to get input from the outside to see if we can get the proper thing written into this draft. So that's one of the topics in there which I think would help getting input on before it goes forward. Cryptographic code management. This is another topic which I think could use some help where this talks about having the validator try to talk to the authoritative server to get the right cryptography going back and forth. I think we need help there. I have my opinions, we have other opinions in the group of people putting it together, but we need a better idea of what should be said about that or not said about that. And finally, the last topic, which I've also found to be something that's bothered me for 20 years on this. When you have a DNSSEC, no. What do you do with it? How do you report that? Do you just log the error somewhere or do you try to alert the operator or someone up a chain? Because sometimes these errors are transient, they come and go. Like if I can't get a key because of time out, that comes and goes. That could be an outage type of thing. If I keep getting the wrong information, then there's something else going on there. You can suspect from the validator why this went wrong and we have to improve, I think, what we can do with some of the error. Because we all know the serve fail. It's all we have. But what can we do to do better than that? The logs could actually have more information about what part of the validation chain went wrong. We've experimented that over the years. I don't think we've ever gotten there. I think that would help, too, with the validators. A validator operates to be more comfortable in operating. For example, when do you put a negative trust anchor in? Your log should tell you. You should try that, maybe. So those are the topics we have in the paper. Comments. Right now, it's not... You can go to the IHTF and talk about it there on the mailing list there. That's fine. Generally, the document like this is not a working group document. It's also good to talk to the authors, because the authors still have the... They're still writing the document. And the three e-mail addresses are up there. Dan Magalt. I say Dan Magalt. I've actually never heard his name said, even though I talked to him face to face. He's the primary author. I've never heard his name that he's done this for years. Myself, and then Dan York at ISC... Isoc, rather. Also has his name on the document, too. You can address a comment to those. Things like this. If you read the document, you think this document is not worth it? Say so. That's a good thing to hear. Nothing like working on something that nobody wants you to do. Also, a question I have is, is this document going to be helpful to those who are writing code today? Do you think that validators are done, and we don't need to worry about this, or do you think that this actually has a real open field for being used by somebody? And to help you find a document, the last part has a title. Densite Validator Requirements. And then that's a link to find the current version of the document. And you can read it there if you choose to do so. So that's pretty much the end of my talk about here. I'll probably put that back up there. And any questions? I don't think anyone here has comments about this. I don't think it was read the draft. I'm not going to do that. But if you feel like you need to say something about this, let me know. It'd be really good if it goes to all of the authors, so we all hear what's going on. So. You did it. It died. Okay. I like the idea, because of the point about pushing up the detection or the revoke in terms of threat intel kind of play for the community. I think that's very interesting. Okay. Okay. Interested in the reporting. Okay. Okay. So the comment is to look at the reporting and the fifth topic. It could be interesting in what you do with the, for intelligence and so on, tracking where the outages are. Any others? You mentioned reporting better information about why validation failed. Have you looked through the current extended error reporting draft and tried to compare that to your report? No, I haven't. Do it. Okay. Is that, is that, this is the extended error reporting draft. Repeat the question. Thank you, Shane. You stumped me on that one. So the question has to do with, do we have you looked at the extended error reporting draft and obviously that, no. Is that a, is that concentrating on the protocol level of reporting things or is that the implementation? So. EDS extension to get more detailed information about it. Okay. Such as expired key or, signatures expired or something. I'll take, we'll take a look at that. What I have in mind, what I have in mind and me as opposed to, as not all the authors, was this is looking more at what the operator configuration logs would have about what's going on internally. So, so not that it's, they're both, they're solving the problem in two different areas. I'm not saying, but that's my, my idea here was, you know, the log files. So. Any other? I think, yep. Yep. Yes. Maybe. Raise interest in this paper. It has a PR problem. So maybe you should look at the title. Word requirements. It sounds like the table will be about requirements of the validators. Not requirements, which validators have. So maybe. Put in the word. Requirements for, or requirements of the, maybe it's the word dependencies. Okay. That's a good point. Okay. The suggestion is to look at the title and say it's not, the title is, is, is misnaming it. It should be requirements for validator. Yeah. The, the environment validators need to do. Yeah. Working on basically titling is what's more accurate for what we're trying to do. Yeah. Yeah. That's a good point. Thanks. Anyone else? I think. Looks like it. Thanks.