**Session Date/Time:** 24 Jul 2026 09:30

[00:00:04] **Rich Salz**: Let's see. Oh, you well, it's gonna ask for approval first. Alexis is posting a slide. A slide?

[00:00:30] **Mirja Kühlewind**: Two sentences. It's my

[00:00:32] **Rich Salz**: my favorite kind of slide.

[00:00:37] **Russ Housley**: Thank you. Well done. Right to the minute too.

[00:00:43] **Brian Carpenter**: Alright.

[00:00:44] **Russ Housley**: Let's go ahead and get started. This is the RFC series working group. We're here for an hour, we hope. This is sort of a note. Well, and the reason it's sort of is we are not in the ITF here. This is the these RFC series goes across more than just the ITF. And still, please treat each other well. And if there are any patent issues or such, please do flag them. Meeting tips by Friday, you probably already know. If you're in the room, please join the Meetecho online tool. If you're remote, please join with the the full tool and use a headset. You'll find it works better. Please keep your video off unless you're present. This is the agenda. We're doing the first part right now, and then we're gonna talk about authorship guidelines and then math and RFCs and then update tags, assuming the presenter comes by then, and then evolving RFCs. Yeah. You should do

[00:02:20] **Rich Salz**: this. So the evolving RFCs is last, but we wanted to kinda give some ground rules on that one just by way of how to start discussing this. There's been lots of good discussion on the list. That is fine. One of the things that Russ and I noticed is a lot of that discussion sort of centers in on IETF standardization process itself. But, of course, we can't change that. That's explicitly out of charter for this group. It is clear that the IETF would be the main customer of such a thing, that that's given. And we certainly shouldn't move forward unless the IETF is willing to use some sort of new, evolved RFC format or way of keeping them. And of course, we're going to have to map the IETF use case into whatever this group produces if we go down this path. What Russ and I are thinking is at some point as we start to congeal, we have an interim with the ISG invited to sort of level set on whether they think this can plausibly go forward, how they would approach this, what our job is, what their job is. So yeah. Jump in. That's fine.

[00:03:53] **Jay Daly**: Thank you, Jay Daly. So this was foreseen in the RFC editor version three process, and that is what the RSAB was created to be with the stream representatives. So it was the the relationship to the streams is meant to go through the RSAB. So I don't this does not sound to me correct in terms of that process having a separate thing with the IESG that, you know, the RSAB is the people to do this with.

[00:04:23] **Rich Salz**: That's fine. I think the discussion is going to be long enough and a sufficient game of telephone if we just speak to the RSAB only, but I think that's a decision for the RSAB. You're correct. That the RSAB should be the one to make if there is going to be some discussion, some communication, they can decide how to have that happen, so whether it's

[00:04:47] **Jay Daly**: an interim or something else. Sure. Sure. Okay. But the what the RFC says that the about this is that the RSAB members are expected to engage in the RSWG to represent the stream positions. So that so rather than the RSWG going out

[00:05:05] **Rich Salz**: That yes.

[00:05:05] **Jay Daly**: Inviting people in, you know, to do that.

[00:05:07] **Rich Salz**: Yes. I I a friendly amendment.

[00:05:11] **Russ Housley**: Yes. But it is the reaction. When when new track was done, it did not go well because there wasn't communication throughout the development process. It was kinda here, this is what we came up with. Do you like it? No. We don't. And then it kinda didn't go well. And we just want to make sure that doesn't happen.

[00:05:35] **Rich Salz**: So I I think you're right in terms of the order of things, but I think we will engage the the chairs will engage the RSAB very directly on this particular topic and say, you you've got to be aware of this and whatever kinds of engagement you want to get going so that we're on the right track is the right thing. But I certainly agree that it is the RSAB's responsibility, not ours, to take that on. Was that the last of it? That was. Okay. So oh, right. So Elliot was running a little late. You'll notice that when we posted the agenda on the list, we had the math one first, but Elliot's got another commitment to the beginning of the meeting. So we figured we'd let Brian present his slides, and we'll do the guidelines for authorship discussion first. So, Brian, you're up to bat.

[00:06:39] **Brian Carpenter**: So the title page is hardly worth spending all your time on, except to note that I grayed out the word ethics because I don't think, in the end, ethics is going to be a major feature of what we end up with, but never mind. It says I've got slide control, so I guess when I press this button, something will happen. Yep. So the problem statement is that questions quite often get asked about who should be listed as an author, who should be listed as an editor, who should be listed as a contributor, what should go in acknowledgments. Just recently, we've seen questions coming up about AI generated content in RFCs. And the the first set of questions are new, of course. They've been around for probably forty years, but the AI question is fairly fairly recent. My position is that readers would expect consistent principles on these points and that most readers don't care about RFC streams. You know, the streams have their own personalities and preferences and procedures, but the innocent reader out there doesn't even read the stuff at the beginning that tells him or her which stream the RFC comes from. So thanks to Elliot, who pointed out that the draft was a bit too wordy. I've now produced a list of 10 draft principles, and if we have discussion today, I'd much rather discussions about the principles than about the words in the draft. So the first principle written down is the principle about consistency. Apply a consistent approach across all streams to all the issues, the ethical issues, and so on surrounding authorship. Why? Because that's what readers would expect. And is there any reason the stream should apply different basic publishing ethics? Now I don't suggest people should answer my question there until they've seen the other principles because it may may make a bit more sense by the time they've seen the rest. The next two principles are about the streams. Each stream determines its own process. The guidelines here apply at the instant that copy is sent to the RPC. So the stream's gone through its process. It's approved what it wants to say. And it's only at that point that the r the RPC could say anything or that, you know, the editorial fraternity could say anything. Guidelines are subject to human judgment and are not rigid rules. They can't be by their nature. And that was thought of when the current crop of RFC editor documents were set up, because there are procedures to resolve this agreement. If the RPC says, hey, there's a problem here, there's a procedure laid down for how that dispute, if it turns into a dispute, gets resolved. So I would claim that the principles defined in this draft do not interfere with the processes of any stream. And Ekr disagrees, but we'll come back to that later. Then these things, I think, are fairly basic. Listed authors are people who made a substantial creative contribution. Listed editors made a substantial contribution to preparing the document, which is subtly different from creative contribution to the document. And listed authors and editors are collectively responsible for the content of the document. I would claim that those expectations or the expectations that every reader has of every document. And, you know, I'm talking about newspaper articles, non fiction books, for that matter even for fictional books, scientific papers, and so on. Again, Ekr can disagree, but I don't understand how you can disagree with those things. Concerning credit, other people who have made a significant contribution have to be listed as contributors or acknowledged. That's basic publishing ethics. Everybody who publishes acknowledge contributions. However, in our context, the determination of who is an author, who is an editor, who is a contributor, or who simply gets acknowledged is definitely the business of the stream. And the streams are independent in their decision making. There is the problem of the style guide preference for not more than five listed authors. But if we're going to say the streams are in charge, then the five authors rule is subsidiary to the streams being in charge as far as I can see. And the last two principles. Material copied from other sources must be acknowledged. Again, that's basic publishing ethics. Everybody does that. And to my mind, that takes care of the AI issue. If some of your material in your document was generated by AI, that should simply be stated as an acknowledgment, just like stating that we copied a bit from here or so and so wrote this bit, but doesn't want to be listed as an author. And the tenth principle is material from other sources must not be copied without the right to do so. That's basic ethics. It doesn't interact with the AI thing because we've already said we have to acknowledge AI material, and we have to have the right to use it. You know, there's nothing we can do about that last rule because it's the law anyway, under copyright law. So that's it. To my mind, there are two questions. Do we actually want to do this, or do we want to let it slide? And are the principles the right ones? Oh, Ekr isn't first in the queue. Anyway, back to the chairs.

[00:14:41] **Rich Salz**: And please mention your name.

[00:14:43] **Chris**: Yeah. My name hi. Rich Salz. Before thinking about it, I did have a clarifying question on slide six. He said, I just wanna make sure I understand something. If you can go back too. Yeah. Other people who made significant nope. This

[00:14:58] **Brian Carpenter**: is sorry.

[00:15:01] **Chris**: Other people who made significant contributions, that doesn't necessarily you're not requiring or suggesting that they be they can be acknowledged in the collective. Right? Like, I can say the working group helped with this.

[00:15:14] **Brian Carpenter**: I think that personally, I think that's perfectly fine. Yeah. Of course, as we know, there was there is also in a lot of RFCs a contributor section where there you know, where it says, you know, Rich contributed it to this document.

[00:15:29] **Chris**: Yeah. No. I understand. I just wanna make sure that doing when it's appropriate, make acknowledging in the collective is also what you were expecting. Thank you.

[00:15:37] **Brian Carpenter**: Yeah. I believe so. Yeah.

[00:15:45] **Ekr**: Yeah. So so I think, obviously, I think this is pretty wrongheaded. I think a lot of the problem, frankly, is the is the use of the RFCs to fundamentally use the analysis. But I wanna, like, talk about the principles for a second. The first thing is, like, huge number of these are, like, not principle not ethics, anyway. They're purely conventions. And in fact, they're conventions that are not, in fact, that widely observed, or, in fact, are widely not observed. So let me just talk about this point about creative contribution. So it's very common in many situations to have people who are listed as authors who didn't make a fundamental creative contribution. I think this point has been made a number of times about scientific research where advisers put their name on papers. And it's quite common here in BIS documents where people remain on the document even though, like, the main document has, like, changed dramatically. And so they made a contribution. They were told, but they didn't make a contribution to BIS, and they're not responsible for the content in any meaningful way even if they were finally consulted in off forty eight. So, you know, and no one thinks those are and and and I think, you know, the the second case, no one thinks it's unethical. And the first case is is so common as to be I think people maybe people disapprove of it, but it's like, you know, you're taking a a not uncontroversial ethical stand, and and and readers don't have any reasonable expectations here. On the other side, it's incredibly common to people not listed on documents even to make current current contribution. I'm shocked you would think of that otherwise. Have you ever heard of ghostwriting, for instance? So, like, it's just like it's just like it's it's like an incredibly common practice. So it's not like it's purely a matter of convention. It's also common on anonymous documents. I've, like, literally worked on things this year where I made a major contribution I didn't get with it as an author. Editors often do the same thing. So, you know, I've worked on multiple things where I made big contributions to English as an author, nor did I expect it. So as I said, this is just convention, and we have to decide what the convention ought to be. But the idea that there's some sort of, like, major principle, I think, is complete ridicules. To the extent to which these are plausible conventions, the idea that they they get imposed only at the point where, like, we go from, like, Internet draft to RFC. I just I cannot imagine why that would be a reasonable thing to think. You know, if money is convention about giving proper credit. And the idea that you would be like, well, I just wrote this document, and I didn't give credit. Like, the entire time, it was in sitting in a draft, like, four years. And at the very end of the process, what I did was I finally gave due credit. I I I I mean, no, you know, again, in many cases, convention come out of, like, scientific publishing. And and, like, and, like, you would be flayed if you wrote some if if if you didn't give proper credit at eprint archive for five years, and then when it finally went to publication, you add the you add an author. Like, everyone would know that was, like, not okay. So so I just idea that, like, these are only imposed at the very end, but not imposed, like, the the the middle. Like, I understand that, like, you think you should do that because that's, like, that's, like, the hook for doing it in this working group and not doing it generally. But, like, as a matter of, like, if you think it's the principles of how people have to list the authors, the idea that they have to list these authors correctly at RC publication, but not during an ID publication, I just, like, cannot understand how possibly could be correct. So, finally, I wanna hit on this AI point, which seems to be the motivation for so much of this. The oh, okay, Pete. No. I I really don't think it's true that it's it's ineffective. Like, you know, Brian's been presenting this as if this is there somehow, you know, somehow, like, you're unethical if you didn't agree with these, and I'm and I'm pushing back on that. And and the and this so in fact, the whole this whole premise of this this of this presentation is actually, like, quite, is actually quite, is is, like, basically effective. So so if you wanna chat talk to the mic now, please do that. But, like, but, like, I don't I don't think I'm I don't think I'm actually out of line here. The and finally, I wanna get into this AI point, which is, like, why is because it's incredibly common to use machine tooling and not credit not credit the machine tooling. You know, people routinely use Python scripts. They do they do analysis. And the people where they do give credit, very often the point is for scientific visibility, not for not not for somehow, again, like, disclosure of, like, how things happen. So I just like I just to be in this entire document, like, wrongheaded. And if it and if it is to be done, it should be done in in the streams, which the white red ones are the right kind of policy.

[00:20:06] **Brian Carpenter**: I'm not gonna comment because, you know, we just argue backwards and forwards, it wouldn't get anywhere. I I agree. We should hear what other people think.

[00:20:18] **Colin Perkins**: Go ahead, Colin. Hi. Colin Perkins. I have to say that I just fundamentally disagree with Ekr. I think these principles are absolutely fine and the way we usually work. I think offers make a substantial creative contribution. I think that is absolutely the way things should work. And if we are doing things where people are not being listed or where people who have not made a substantial creative contribution are being listed, I think that is a problem and we should be fixing that. I do not believe we permit ghostwriters in the ITF. And in terms of the AI and so on, I I don't think I'm I don't think we're arguing that AI tools should be listed as offers. I think we should be documenting the tools we use to produce RFCs. And I think if people are using AI tooling to do that, they should document that. If people are using other scripts and tools and Python scripts and whatever, they should be documenting and releasing those tools as well. So I I think these principles are absolutely fine, and I I would encourage them.

[00:21:30] **Brian Carpenter**: Well,

[00:21:36] **Chris**: Hello. Chris from Huawei. So I I wanna drill in on the AI attribution or acknowledgment piece. Struggle a little bit with what the the purpose of of doing that is. I mean, to me, it's it's it's a tool. I mean, it can be misused. I mean, it can get into, you know, in a you know, it can get into plagiarism and, you know, on, undocumented attribution and blah blah blah. But, you know, if ultimately, authors remain responsible for the content and originality and, etcetera of their their document, I think trying to parse out the tools that they've used in any along a continuum, which can range from background research to, you know, proposing a a flow for a document to suggesting specific language to doing anti plagiarism checks. It's all specifically very useful for non native language speakers. It generates a much, improved product. And I think the the the more they make use of it, the better that that product is. I mean, tending to to large parts of the actual writing. But I think everybody's gonna make significant use of it to improve their their work products. So what kind of a statement would you make? Like, where's the threshold to acknowledge that, you know, AI was involved? This is supposed to be some kind of pejorative in a sense or, you know, gee, we wanna know if you used AI tools in in this. I just don't see the the the point or that it's sustainable. But, you know, if we're gonna do it, like, what what does it mean? Is it you know, you need to say it if you used it for these kinds of purposes or if AI tools came anywhere near the production of this document, you need to list it. I mean, I don't see how that works.

[00:23:47] **Brian Carpenter**: Well, I'll tell you how I think it would work. But you'd actually have to go and read the text of the document because what I put in the text of the document is that it's using AI to improve your grammar, or for that matter to translate if you have difficulty writing English as a non native speaker, is just like using a spell checker and doesn't raise any issues. But the issue is if you actually have said, you know, dear chat GPT, please write me a new protocol design for two intelligent agents to talk to each other, and then you cut and paste that straight into your draft.

[00:24:34] **Chris**: Well, again, where's where's the if it's a bad result, that'll come up in the review. I mean, yes, That's why I say the authors still have to assume responsibility Yep. Absolutely. The content of the document. But trying to parse what role this tool or that role played in its formulation, whether it's on an ideas level, flushing out the ideas level, or the actual writing level, is is to me, it's immaterial.

[00:25:02] **Brian Carpenter**: I think that's probably going to be debated at length in our in our society for a long, long time. Right? If you look at what the IEEE decided, you know, they decided they want disclosure. And and and, you know, they publish a lot of standards documents, and they publish a lot of academic articles. If we don't want any kind of disclosure, that's a possible decision, but it's one the community would need to reach some sort of consensus on. And frankly, from what I've seen of people's reactions to AI generated texts over the last six months or so, we don't have anything like a rough consensus in the community.

[00:25:45] **Rich Salz**: Gene? And if you have further comments, Chris, you can certainly put yourself back in the queue.

[00:25:54] **Chris**: Sorry. I just again, I wanna leave it as if you're going to include it, you have to be clear what's the threshold. Yep. Because that AI would not be connected in any way with the path along the chain to the production of a document is probably not going to happen at all going forward. You need to find kind of threshold for when it needs to be mentioned. And the the issue I'm raising is I don't see where such a reasonable threshold with justification would be.

[00:26:30] **Rich Salz**: Thanks, Chris. Jean, you're up.

[00:26:39] **Jean Mahoney**: Hi. Jean Mahoney, RFC Production Center. So I'm going to cover several topics here. One of them is on the slide was the this starts applying when a document enters the queue. But many of these things are things that the RPC can't know and can't enforce. For instance, we do not know. We take as given that the listed authors made significant contributions. We could suspect during final review that maybe one of these authors just had their name added to it, and they really haven't been following along. But we can't say, oh, this guy, you know, was just added to, you know, round out the the header or what have you. And, also, when it comes to, like, AI, like, the enforcement of if text comes in and it hasn't been identified as, oh, this was generated by AI, we don't have the tools to say, oh, we've scanned your document and we have found suspicious text. Could you please say whether or not it was generated by AI? I guess we could add tools like that, but this seems like something that should be done earlier in the drafting process. Also, a really quick question. What's an editor

[00:28:26] **Brian Carpenter**: when it

[00:28:27] **Jean Mahoney**: comes to the label on an RFC? And we also had a a principle about identifying the editors. Do we put our RPC staff on every single document? We we don't we haven't done that, and people don't acknowledge our work and contributors or acknowledgments. So I I know that editor is actually not defined. I I haven't found a whole lot of guidance other than it tends to be somebody who holds the pen for the group and is not adding their own original text. But, again, something RPC can't you know, we're not following along in the process. So if somebody says, hey. I'm an editor. We're like, great. We will ensure that it says Ed by your name. We in yet another topic, maybe something maybe we should just write down what the policies, procedures are for the RPC right now. How we handle authors. We have options for missing authors, authors that become unavailable. So we do have author names that remain on the the RFC even though they have passed or they or the the text has drift changed significantly from the RFC they wrote, and we have stream representatives approve in their stead. Anyway, lots of comments there. I just wanted to get all that out.

[00:30:12] **Rich Salz**: So and just a chair thing there. I think it would be very useful to get current policies. It doesn't have to be a formal document, but just sort of scribble up a list Because one of the things I'm trying to get my head around in Brian's document is what is a representation of what we're all thinking now and what is literally new policy that's being proposed, which is within our charter to do, but separating those out would be a very useful task. Okay.

[00:30:45] **Brian Carpenter**: Yeah. I'd also like to say to Gene, I don't think the intention would my intention, certainly, would not be to make you into the police for this business. Being ethics police is difficult enough. You know? I think it's more a matter of if the stream asserts that it's done all this stuff right, then it's not your problem. And that's my that's my personal take.

[00:31:20] **Elliot Lear**: Okay. So Elliot Leer here. And I guess it's good evening, Brian.

[00:31:28] **Brian Carpenter**: Good evening. Yes.

[00:31:29] **Elliot Lear**: Couple of things. First, from a independent submissions editor standpoint, generally speaking, I wanna know that the people who are listed as authors have actually done work and have actually provided that creative contribution. So I think that's consistent with principles here. The on the whole, right, the question, I think, really before us is whether we should work on this in terms of separating out each of the issues and then going through and saying, well, yes, we agree with one. No. We agree with we don't agree with one other or something like that. I think that's really a question in front of us.

[00:32:09] **Rich Salz**: Yep.

[00:32:09] **Elliot Lear**: The the one the the last point I'll make at this point is that I think the enforcement of all of this has to happen in the streams. I mentioned that in the chat. The reason I mentioned it in the chat is the reason I mentioned it, though, is that I agree with Gene that I don't think that this is something the RPC is in a good position to enforce. But just because the RPC isn't in a good position to enforce doesn't mean that the streams aren't in a good position to enforce it. They they they you know, an area director should know or that working group should know who would who was it that actually did the work on this. It should not be something that should be that difficult. And in fact, in my experience, it it varies considerably from from Ekr. I do occasionally see someone who I on a draft who actually hasn't done a lot of work on the text, but they've done a lot of work in other ways. That's usually good enough for me, you know, either as a participant in the IETF or the independent submissions editor or in the IRTF. I don't see that as much of a difference.

[00:33:12] **Rich Salz**: So we've gone and closed the queue at this point. So Mark's last in the queue. Please do keep your comments as concise as possible.

[00:33:21] **Jay Daly**: Jay Daly, and I'll be brief. So this is really in response to Chris back there. I'm not sure if you're aware, Chris, but I suspect, I don't have any proof of this, that there are people participating in the standards process who do not understand what the AI is writing for them. K? That they are involved in highly technical things. They have an AI that is doing all of the work. And if you took the AI away and just said to them, please explain what that AI has written and you have posted in your name, they would not be able to do it. So this goes you know? So no matter if you ask that person, do you stand by it? You know? We've still got that problem that people will say yes to that even though they absolutely could not, under any circumstances, understand it.

[00:34:10] **Russ Housley**: My

[00:34:16] **Martin Thomson**: goodness. Mutton Thompson. I I find this debate quite tiresome, and I I agree, Jay, that this is this is a problem. I agree that there are problems with what's happening, but the problems exist because the quality of the work work is poor and the volume is enormous. Those are the problems. It doesn't matter what tools people are using. You disagree. I strongly disagree with you. It's my turn to speak now. And I think the to the extent that AI disclosures are mandatory, they become something that people hide behind. And I don't know where to draw the line, to Chris's point earlier. And I would I would strongly oppose any notion that we encourage or require someone disclose the use of the tools that they're using to produce the text because we have the the much high level principle, which is that you are responsible for what is what you are signing your name under, and that is sufficient.

[00:35:20] **Mirja Kühlewind**: Thank you.

[00:35:21] **Brian Carpenter**: Yeah. I'll say, Martin, thank you for bringing in that responsibility point, because I hadn't thought of that at the beginning, and I agree with you that it's it's the most important thing.

[00:35:35] **Ekr**: Thanks. Pete, I do wanna walk back nonsense. I apologize for that. Think this is wrong, but I could use a chosen different word. So the I wanna I wanna make I wanna step back and make two points. First is, Brian, do you agree to these that that if this Druzhir adopt these practical matter, they'd have to be enforcing them all along the way.

[00:36:01] **Brian Carpenter**: The the streams would have to sign on. Yeah. I mean, precisely because the reasons Gene gave why why the RPC can't just do it.

[00:36:09] **Ekr**: But I I I I agree. I I I agree. But Scion is different. What I mean is that let's say for the sake of argument, this AI disclosure. Right? That as a practical matter, that would mean the AI disclosure have to appear at the point tester introduced. It wouldn't be reasonable for the streams to be like, well, you know, you can be nonconforming all the way up to IESG, but the IESG makes you do it the end. Right?

[00:36:30] **Brian Carpenter**: I agree. It's sort of when you're when I'm developing a document, I try to put in the acknowledgments, you know, in real time. You know? When I when I when I put a change into the text, I add the person who suggested it to the acknowledgments.

[00:36:45] **Ekr**: I I think Well, that that that that was my expectation as well. Okay. Good. I'm glad we are on the same point about that. I think we we may draw different conclusions about what about what that means for the rest of for the rest of this conversation, but I'm glad we agree with the facts.

[00:36:58] **Brian Carpenter**: As in, you know, section 1.1 was was written by. Right?

[00:37:04] **Ekr**: Sure. So I I think I I wanna circle back to the the the I do I do think this data disclosure thing, unfortunately, is the heart of it, although I really thought that we might wanna discuss individual principles. Like, the, I also have problems with, like, the vast use of generation of AI for text generation, but I just don't think that this really hits on it, because I think this comes at it from the sort of credit view. And but the real problem we have is the one Jay is the one Jay introduced, which is that, there is, like, a, lots of people who are just using the AI to generate text to engage in the conversation, do not understand, what they're saying and aren't really able to plausibly engage these. You're arguing you're arguing with a zombie. Right? And that, I don't think this is a very good job of distinguishing those things, but part of the problem is because a huge amount of problems on the mailing list, not on drafts. And part of the problem is that it sort of phrases it as as a as as a a disclosure issue rather than as a responsibility issue. And so I think we I think if I think if we want to have an AI, discussion of the use of AI and IT, if it really needs to sort of come back to Martin's principles and has a more kind of general view of the world than one about, like, you know, the relationship of the the relationship of of the author of their text in the case we're talking at here with the AI is different relationship with the author to author text in the case we're talking about author disclosure. So I just need Mark at the mic. If Mark and I jointly author a document, right, you know, we don't individually identify which sections Mark wrote and which sections I wrote, and nobody thinks. And people think that if I'm I'm supposed to, like, you know, be responsible for the the document as a whole. And if I push the document, nobody's like, you know, nobody's like, you know, don't just say, Mark actually wrote the the whole thing. Right? But in the in the AI AI case, think precisely that's a concern. And, so I just don't just think that, like, the relation with the author the author the the author and text in the AI is a complete different issue with the author and the text in in in this coauthorization case. I just think trying to, like, lose them to the same thing as kind of a a kind of, like, a crediting issue just doesn't really hit the main the main problem or concern. But I'm gonna I'm gonna I'm I'm done. So I'm happy to engage you that or not. But

[00:39:23] **Rich Salz**: Yeah. And and, Brian, what I said in the chat just before is, in response to Elliot, is maybe the job here to see if this is something that can eventually get consensus in this group is to go back and reframe this solidly in Martin's terms about author responsibility and not about tools and see if that gets a little more traction here. Mark, you get to close out the queue.

[00:39:52] **Mark Nottingham**: Mark Nottingham. Yeah. That that sounds like an interesting suggestion. I got up to say, you know, regarding AI, as we've learned in the AI preferences working group, these are relatively deep waters. It is rarely binary as to whether something is generated by AI. It's endemic in the stack for a lot of people. It's everything from spell checking to their search to everything else. And so, you know, it's not really meaningful to say that chunk of text was generated by AI. I also noticed you you you you you characterized it as copying. You know, if you talk to the legal folks, they'll say that, well, that's a doubt as to whether that actually serves as a copy or not because AI is not a person,

[00:40:31] **Ekr**: and it

[00:40:31] **Rich Salz**: doesn't have a legal personality.

[00:40:33] **Mark Nottingham**: So I my inclination here would be to carve the AI aspect out of it and and, sure, talk about responsibility. That's fine. But there obviously needs to be a much larger and then very nuanced discussion around AI in general in standards participation, not just in terms of authoring, but in all the other aspects of participation in the ITF. And I don't think this working group should preempt that. I think that that it needs to be integrated across the entire organization, and we need to have the careful consideration of the incentive structure. So for example sorry. Can we get the slide back up? Because I did wanna talk about one other thing there. We need to think carefully about the incentive structures as as Martin said, you know, especially when you say you must disclose. I early on said, when in in the tool that I have With the Yes. So mandatory disclosure is is important, but the incentive structure that sets up for participants is is kinda setting them up for failure. And, you'll have people who try to avoid it and then jump through hoops, then we get into this, you know, cat and mouse game. So I think we need a a broader discussion of it. Regarding, since the slide's not back up, I'll do it from memory, which as we all know is quite flawed. The the notion that you must, cite all of your sources, I think, is also something we need to examine carefully because I've had disagreements with people about how far that goes. For example, I have very memorably, someone, complained to me that, you know, you have a draft, and it is very similar to this previous work which you are aware of. Therefore, you should cite it. And my answer was, well, this is not an academic paper. This is a standard. So we need to be very crisp about that because we're gonna have disagreements.

[00:42:24] **Rich Salz**: Thank you. So I I think, Brian, you have I don't I don't think we've heard enough in here that this document in its current form is going to gain traction, but I think you've gotten at least a little feedback of things that might.

[00:42:42] **Brian Carpenter**: Yeah. Absolutely. But I'm gonna have to review the the chat and so on afterwards, see exactly what to do next. Appreciate it. Thank you, Anurag.

[00:42:53] **Rich Salz**: Alright. So math and RFCs, I originally had this slide as simply saying we're done. Right? But Elliot cornered me in the hall and said the discussion that's currently going on in the list, he had another little tweak to, so I asked Alexis to put together the currently proposed text on the list and see if we can put a spike in this quickly. Elliot, did you want to put well, we'll make believe you're in the queue.

[00:43:24] **Elliot Lear**: Okay. Thanks. I I would just make two a two word change or two or three word change where it says the RPC is expected to adjust their requirements on on this as they gain experience, I think that what we're saying is the RPC may adjust requirements on this as they gain experience.

[00:43:42] **Jean Mahoney**: Okay.

[00:43:43] **Elliot Lear**: That's it. That's let's not set expectations. We'll just deal with it. You know, you can make changes, RPC, on on this as it says, on requirements on this, actually, the antecedent may be a little unclear as well. So if other people see it see it as unclear, then then we should make a change. But otherwise, you know, I can live with that. That's it.

[00:44:07] **Brian Carpenter**: Gene?

[00:44:13] **Jean Mahoney**: G Mahoney. Alright. So if the RPC adjusts the requirements to where we say, no. You can't have simple text, in line and and start overwriting authors, is that an okay outcome from this paragraph? I mean, I'm just wondering what our I

[00:44:41] **Rich Salz**: suspect reading the second sentence, simple text may be used in some cases when the author prefers it, that there might be pushback and say, the RPC in saying absolutely never might have violated this Okay. Principle that we, the RSWG, put down.

[00:45:04] **Jean Mahoney**: Okay. So I'm just, you know, looking at what adjusting our requirements,

[00:45:09] **Rich Salz**: what the scope is. What the limits are. Yes.

[00:45:11] **Jean Mahoney**: And usually, you know, if an author pushes back, we we don't push. So

[00:45:18] **Rich Salz**: So I I think, you know, the the general rule is we set a policy, you attempt to live within that policy. If there's disagreement, there are ways to deal with that disagreement.

[00:45:29] **Jean Mahoney**: Fair enough.

[00:45:32] **Rich Salz**: Elliot, you had something else?

[00:45:33] **Elliot Lear**: Yeah. I was just gonna say, let's not assume that either the authors or the RPC are stupid or incalcitrant. Both in in in almost all cases, a solution in all cases, a solution is found, I have to say.

[00:45:50] **Rich Salz**: Have Martin Durst in No. Martin is not in the room. The the other Martin. Okay. Durst.

[00:46:01] **Jean Mahoney**: Martin

[00:46:04] **Rich Salz**: Thompson looked very frightened for a moment. Doesn't want to do anything with math. Is anybody else

[00:46:13] **Jean Mahoney**: He's one of the all things.

[00:46:14] **Rich Salz**: I know. He's the Being ironical. Does anybody else want to comment on this text as amended by Elliot? Or can we go to the list and say

[00:46:33] **Russ Housley**: You mean Martin can explain this text? Well Some AI didn't write it.

[00:46:38] **Rich Salz**: Yes. Okay. No. Be nice.

[00:46:44] **Martin Thomson**: So, Ross, that it doesn't work that way. Once the text is written, it means what it says. Sorry. And if we don't like if we don't like what it says, then we change it to mean something that we do like more. Yeah. And I think what Elliot's amendment is is perfectly fine. It's a friendly amendment, and we should just do that. That's that's easy.

[00:47:02] **Rich Salz**: You're okay. The chairs will now limit their ironical comments. Exactly. Okay.

[00:47:10] **Russ Housley**: So so we we are done with this document now.

[00:47:14] **Rich Salz**: The belief in this room is that we are done.

[00:47:18] **Elliot Lear**: Yay, team.

[00:47:19] **Russ Housley**: Alright. We we'll send it to our side.

[00:47:23] **Mark Nottingham**: Mark? Just a naive question, Mark I and I I I've watched this discussion go by, but I haven't really paid attention to it. So par for the course. Second sentence, simple text may be used in some cases when the author prefers it. Is somebody gonna interpret that as the author's preference prevails? Just wanna make sure the intent is clear here.

[00:47:48] **Russ Housley**: That's how I interpret it. Yeah.

[00:47:50] **Mark Nottingham**: Okay. Just just wanna make sure.

[00:48:02] **Jay Daly**: Sorry. I know it's in lowercase, but the may word may, it's not will. It's Right. So I don't interpret that they use the author's preference, you know, Winchester.

[00:48:16] **Russ Housley**: It's not an uppercase, right?

[00:48:17] **Rich Salz**: It's not a hard requirement that the author always prevails here, I believe.

[00:48:26] **Jay Daly**: Absolutely. Good. Okay.

[00:48:33] **Jean Mahoney**: That that's the RPC is expected to exercise discretion. Yes.

[00:48:39] **Mark Nottingham**: Alright. What up on I I just imagine the, you know,

[00:48:45] **Rich Salz**: foyer and the Absolutely. Yeah. I think we're going to do Mirja's document. Mirja is here.

[00:48:55] **Russ Housley**: Yes. She is.

[00:48:56] **Rich Salz**: And she has slides and everything.

[00:49:01] **Russ Housley**: I suspect with 10, we will not have time for as much debate as is needed.

[00:49:08] **Rich Salz**: And just to preempt any concerns, interims are always a possibility, and we can set that up for the other discussion if needed. The floor is yours.

[00:49:20] **Mirja Kühlewind**: Yeah. Hello. I'm here. I don't want to talk too much about the document itself, but I really want to understand if there's interest in continuing any work in this space or not. Because the list discussion drifted quite quickly off in a different direction. So the updates text, we all know it because we love to discuss it. It is vaguely defined in RFC 22, 23, but it's it's not, like, sharply defined enough that we're using it in a uniform way. So if you look at how it's used in the RFC series, it's, like, all over the place. That's a short story. So what what's the problem here? The problem is that we keep discussing this. Right? Like, especially when I was on the IESG, but also in working groups, have lengthy discussions if the app text should be used or not, and that seems like very unnecessary. And the other problem is also it's like because we use it so broadly, I'm not sure what the meaning to the reader is. If it has like any more meaning than just like this is a reference to an already published RC that might be or might not be important. Some people think there is more meaning to it, and other people don't think so. But the reader doesn't know anything about this because it's not really conveyed like when somebody decided to put an update take on what they actually meant. The draft, this is my one slide about the draft, proposes three new tags to separate these things. So, amends, extends, and also see also. When we put these tags together, we thought we think these covers effectively all use cases because the c also is so broad that it covers everything. But we also analyzed a couple of RCs, and we saw that both of the first two use cases are used very often, and there are a few that doesn't fit in. That's why we have the See Also tag. Why three tags? Because we had so much discussion about the updates text, we seem like we're not agreeing there, so one way out might be just to define something new. The one thing we do agree on is that this old new style where you really say, I want to replace this piece of text with this new text, that is for sure covered by the update text. But there are strong opinions about if anything other should be covered or not. That is the part we don't agree on. But it also addresses the second point I made. It really provides a much more clear signal to the user, which goes beyond just having forward reference. And maybe we don't need that, but it does provide this feature, basically, and that I think is actually something that some readers are looking for, or implementers, I would say. But the point is really, is not only providing more guidance about how to use it, it also hopefully helps discussion if or if not to use an update tag, because that's what we have the most discussion about. But if you have these more clear tags, I think the cases where it's completely unclear which one to use or if you want to use any, they should minimize. But, I mean, we are guessing. So, as I said, this was brought up recently this list for this group. There has also been previous discussions, so the ISG made a proposal. They wanted to define it, and the outcome of that kind of consultation was like, no, we don't really agree. And then we started writing the draft. Then there was some more discussion about the draft in other fora. So this is like the third or fourth or fifth discussion we have about this, and I see this every time. It it goes off quickly into various directions with, like, a lot of proposals. Every time, slightly different directions as well, but it's not, like, clear that we can reach any consensus here. So, like, you know, like, what happens every time is that there's a bunch of proposals, like how to use instead of three texts, have two texts. All kind of combinations came up, like, we only need amends and a 10 x tens, we need amends and see also, we need update and see also, or just one tag, any of these. Right? So all these proposals are always on the table, and I'm not seeing any any real progress. And I think the reason is what I intended or what I was hinting to earlier is that we all agree on this basic case, but we have really, really strong opinions from people who think we should use it either very broadly and not define it closely, or people who think we should really only cover this one clear case and provide clear guidance. And that's where we're not getting together and finding consensus. So my question really is, how can we find consensus? Like, how can we make any progress here, and do we want to make any progress? I know that people think, like, this problem would go away if we have a different model, but we don't have a different model, and I don't think we will get there quickly. So I think this is still a problem we should try to address now because it creates all this unnecessary discussion and that's annoying.

[00:54:14] **Russ Housley**: Elliot.

[00:54:19] **Elliot Lear**: Myriad, thank you for this draft. And be I I thank you and Suresh for two reasons. First of all, I I realize you're trying to solve, some some real ambiguities. And actually clarifying updates, think, is useful. However, I think the real value of your work has been to spur on the discussion that followed, which is what do we do with the series as a whole in terms of making it more readable to engineers as and when documents change. All this is to say that I think we should focus on that effort and take this input as part of that effort. There's no reason to rush this. It's been as broken as it's been for as long as it's been. It's not gonna it's not gonna harm us if we step through at a at a more reasonable pace to look over the work and that that is following. To that end, I'll just, you know, do a little advertisement here and say, I really like the mock up that Eric did, for instance, online. So I would put this work aside for now, but not forget it just as we're going through the discussion of the neck on the next part, see how we interact on that.

[00:55:31] **Mirja Kühlewind**: I mean, my understanding was that the discussion of the net next part would probably not would remove the need for any of these texts potentially. Right? Not sure. Yeah. Okay. Yeah. I mean but like you also said, you you you think we should define the updates text, but still not now. Okay.

[00:55:49] **Elliot Lear**: I will put it on the side for now and see how the rest plays out.

[00:55:52] **Rich Salz**: And to the microphone, Elliot said I would put it on the side for now and see how the rest plays out.

[00:55:57] **Colin Perkins**: Colin. Hi. Colin Perkins. So I I don't greatly object to this. If you want to publish a document along these lines, I think that would be fine or at least not harmful in any way. I also don't think it would solve any of the problems. I think we would just be having the same discussion about the exact meaning of amends or extends in the future. And to be honest, I don't think that the updates tag, at least in it to to the way I have seen it, I have not seen any problems with the updates tag at all in the past thirty years I've been involved. So I I just think this is a a non problem. I don't see any harm to this. I don't see any benefits.

[00:56:40] **Mirja Kühlewind**: So I think the the discussion comes up from time to time in the working group, but the working group goes through it and they go on. Right? It's not like a huge waste of time even so. Feel like it's every time the same useless discussion, but okay. But it comes up, like, all the time on the IHT. That's why we started it, and you can also say whatever we go through it. But like, I think I'm I'm I mean, like

[00:57:01] **Colin Perkins**: I I would I would just suggest the IESG needs to care less about this. It's not it's not important either way.

[00:57:09] **Mirja Kühlewind**: I mean, this this started out of the ISG that started the draft. It was just like also me being lazy and moving forward because I don't know how to move it forward. But, I mean, it's not like the worst problem we have, but I thought it's actually a problem that is solvable. And I I mean, I agree with you that the discussion will not go to zero, but I'm pretty sure it will reduce. But, you know, who knows? Yeah. I just wanted to say, to be fair, like, people also raise concerns about adding more text that would actually create even more discussion. Again, I don't believe that. We all don't know. I agree with you on that point that I don't think adding the tags will be harmful.

[00:57:48] **Colin Perkins**: It's not going to harm anything. I just don't think it will solve any of the problems we're having either. So

[00:57:55] **Russ Housley**: Okay. We're down

[00:57:56] **Brian Carpenter**: to I

[00:57:56] **Mirja Kühlewind**: mean, was phrasing two problems. As I said, I think we will address the ISG discussion. Maybe this is not the most important problem to solve.

[00:58:05] **Colin Perkins**: I think the ISG will argue about exactly what amends or extends means instead. But

[00:58:11] **Mirja Kühlewind**: I wanted to say on the the problem with the readers, that's actually something which would be nice to assess a little bit about. Like, if how how implementers use the update text. I don't know.

[00:58:23] **Russ Housley**: We have two minutes and two speakers. Please be concise.

[00:58:29] **Ekr**: Hi. Yeah. The way to stop talking about this about this is to stop talking about this. I think you're probably we're supposed to spend and the amount time for us to spend on revising these definitions will will probably eventually exceed the amount of time that was actually spent discussing them later, although maybe not. I'm not actually sure it's gonna solve the problem as Colin and, and Elliot has suggested. So, unfortunately, I just don't think this is, like, actually gonna help us very much, and we shouldn't do it.

[00:58:57] **Russ Housley**: Suresh?

[00:58:58] **Suresh Krishnan**: Yeah. Thanks. I think, like, like, Miria said, right, like, we drove this up because we saw the problems. And there's, like, cases where this problem is Edison, and there's, like, RFCs now that use this, like, kind of outside the process to do it. So there's, like, RFCs in, I think, like, six low and, who actually used this to actually do it. And there's, like, very positive feedback from the implementer saying it was very useful for them. I for me, I personally care about consistency in what we mean by updates. And, like, one key thing that I found useful is that if I go once an RFC is published, it's immutable. Right? So the the reverse link from the RFC, right, the the updated by or the amended by thing is more useful. Because if I'm looking at an RFC and there's, a mandatory change that happened to it, I would like to know about it. And that's kind of if you can signal it anyway, like, you know, like Elliot said, like, there's probably better ways of doing it. I think, like, Martin was also looking at something on that. I think it's good, like, know, whatever happens here, but I think it's just to talk about this issue has not gone away. So, like but not particularly sold on in one solution. So thank you.

[01:00:06] **Russ Housley**: Thank you.

[01:00:07] **Mirja Kühlewind**: So what like

[01:00:08] **Russ Housley**: I think we continue on the list.

[01:00:10] **Mirja Kühlewind**: Oh, we do. Okay.

[01:00:11] **Brian Carpenter**: Who's ready to give

[01:00:13] **Russ Housley**: take Elliot's idea and Yeah. Combine it with the next topic as well.

[01:00:18] **Rich Salz**: Right. I I mean, I think Elliot's point is, you know, well taken that let's see let's hold this on, you know, in abeyance, because it might very well play into the next topic and see where people want to go with this. Because if the next topic breaks down and goes nowhere, maybe people will be much more interested in this. But I do think the hold until next topic gets some Some try. Some discussion.

[01:00:47] **Mirja Kühlewind**: That also means I will not do anything. I will wait until somebody pings me.

[01:00:50] **Rich Salz**: I I I think you are in a a hold pattern at the moment.

[01:00:55] **Russ Housley**: So, obviously, we did not get to all the topics. We will need to have a poll about when when to hold an interim. We're out of time. And so thank you very much, and, look for that poll on the list.

[01:01:15] **Rich Salz**: Enjoy your lunch. Lovely noise.

[01:01:29] **Russ Housley**: Well,

[01:01:33] **Rich Salz**: it could've been. Yeah.

[01:01:35] **Martin Thomson**: We'll be seeing you on

[01:01:36] **Colin Perkins**: the list on on on

[01:01:37] **Elliot Lear**: the isolates for dealing with the asa.one.