Session Date/Time: 24 Jul 2026 12:00
[00:00:34] Mark Nottingham: Awesome. Okay. So this is the AI preferences working group. It is Friday afternoon, so let's try and hold it together. What's our remote participation looking like? 37. Camera. So Okay. Let's let's give everyone just a moment or two to come into the room, since it is on Friday afternoon. And, I don't think we're gonna be using all of our time today, but we'll we'll see. When we do start get started, if someone could close the door in the back, that would be much appreciated.
[00:01:18] Speaker 1: Thank you, Peter.
[00:01:45] Suresh Krishnan: Suresh wants me to stay on the slide for the whole meeting, but we had to show the note well.
[00:01:51] Mark Nottingham: I don't I don't think we're the ITF smallest and craziest working group, but none none on both counts at
[00:01:57] Nate: least. Alright.
[00:02:04] Mark Nottingham: Let's go ahead and get started. This is the note well slide. It's a reminder of the policies under which we all participate here in the ITF, especially regarding our behavior. We do take the guidelines for conduct and the anti harassment policy seriously, and we expect everyone to behave professionally towards each other. Also, regarding intellectual rights oh, if just make sure that door closes. Okay. Good. Your contributions here fall under the policies that are listed there. You need to understand those, so please do talk to your lawyer if you don't. Also list the standards process. You're eager to get going, aren't you? The standards process. And especially, this meeting is recorded. There are photographs taken, so make sure you understand and agree with that. If you have any questions, any issues, talk to your chairs, Suresh and I, as well as the area director. Can we have someone volunteer to take minutes? We do have the AI tools for that, but we prefer humans for now. Anyone volunteering? We can choose a bunny. Maria needs to go.
[00:03:22] Suresh Krishnan: Brian said yes. Thank you, Brian.
[00:03:23] Mark Nottingham: Thank you so much. Very kind. So our next slide, we're gonna do a quick status update. We're gonna talk as part of that about some future meetings just to to start that conversation. We have at least one and and perhaps two pull requests to discuss, and then we'll go through the issues and have just open discussion. This is a plenary meeting as part of the ITF plenary weekly meeting, but we we don't have a lot of the folks who've been involved in this work in the room at least. And as always, we're not gonna be making decisions in this room. We're really just discussing the work as it's been happening and circulating it with the wider IETF so that we can get some awareness and some input. So status. We had a a working group interim in Toronto a little while back now. I think as chairs, we thought that went quite well. We had some good discussions. And importantly, it seems like we had some people actually listening to other folks and and and moving the work forward and and coming to some understanding of other people's positions. And that that was really encouraging, I think, for us as chairs. So we wanna continue that. We wanna continue the momentum there and and that spirit. There's certainly work left to do, but we we see some signs of of hope in that. Anything you wanna add, Suresh? Yeah. I think, like,
[00:04:48] Suresh Krishnan: there is a pattern in this group where we tend to make a lot more progress in the interim meetings than in the plenary meetings. I think it's like Mark said, it's really at the we have a higher bandwidth and more time to look at things. And thanks everyone, like like Mark said, to kind of sit together, listen to everybody else, and come up with proposals. We do have, like, one thing we kinda wanna go over today, but, any anytime we run for a difficult issue, this is kind of how we made progress at the interims.
[00:05:16] Mark Nottingham: And and I think I'd echo that. I think, you know, we we've been trying to get more asynchronous progress, more progress in the mailing list. That's really how we can get this work concluded. So I think we're we're gonna probably be pushing for more interaction and eventually decision making on on the mailing list rather than relying on the interim meetings. That having been said, we do wanna finish this work in a reasonable amount of time. And so we've been talking about what our our meeting schedule is. We think that in consultation with with IRTF leadership, we can probably take it up a little bit and make sure that we we have more interim meetings scheduled to give people some predictability and to make sure that we get a good pace for for the meetings. That has to be, balanced against people's ability to travel and availability, obviously, but, we we we feel like we can probably schedule a little bit further out. And so right now, we have a meeting scheduled in the end of August, early September in London, if you'll recall. We've been talking about the possibility, and we've we've talked to Roman the ITF chair, about scheduling, as well as our kind area director, in purple over there, about having a meeting kind of in the roughly October time frame. And even, you know, looking further out, perhaps we can look at something like January. So as always, if if you're able to host an interim meeting for us, please come and talk to Suresh and I. We will have more information about that on the mailing list. I think we might do a poll try and figure out what people's availabilities are and what the constraints are. But, look out for that so that we can continue the work. Any questions? Okay. Let's dive then into, the work. I think we wanna review two pull requests. So could you get a browser window open?
[00:07:19] Suresh Krishnan: Do you want screen sharing?
[00:07:20] Mark Nottingham: Oh, I can I can try? You know what? Let me try to do that, actually. Someone is knocking. Who couldn't be at that door? Do
[00:07:52] Suresh Krishnan: you want me to share?
[00:07:53] Mark Nottingham: If you'd like. Yeah. If you're ready. Okay. So, I think the two we wanna discuss today are
[00:08:13] Suresh Krishnan: Which two? It's 213.
[00:08:14] Mark Nottingham: I think 213 and then 211. Yeah. So let's try to discuss 213, and maybe go to the diff view. So this is section three dot two, and this was inserted a while back. And I think at Toronto, we identified that it was it was probably too detailed, and and perhaps, creeping out of the scope of what we as a group are authoritative for. Bigger? I think he's saying bigger. Only Oh, only show the green. The graphic designer's favorite thing to hear, make it bigger. Yes. Lovely. That's good? Okay. People in the first row at least can read it. There are plenty of open seats in the front, by the way. So, after a lot of discussion in Toronto and then afterwards, we had a group of people go away and have some more discussion about this and came up with a pull request, to to pretty dramatically cut down the scope of this subsection. So this is the proposal. We wanted to talk through it. I I I've seen a lot of back and forth on the mailing list about it. I want to note especially, there have been a couple of claims that, oh, it's not possible to get consensus here. Well, that that that's
[00:09:44] Glenn Dean: not true.
[00:09:46] Mark Nottingham: Just no one person or one argument can stop consensus. It's more of a question of have we established their support for it? Have we worked through the objections and make sure we understand them and then handled those objections appropriately? So let's talk about it. I think let let's, first of all, establish support for it, which I think we we've heard a number of people express support for this, but let's talk through that. And then look at the objections and see where we sit. Any any of the proponents wanna get up and have a a go at describing what's been done here?
[00:10:23] Suresh Krishnan: Timid robot. Go ahead.
[00:10:25] Mark Nottingham: Timid robot, actually. Yes. That's him. Sorry about that, Timid robot.
[00:10:28] Timid robot: So I think first, I wanna call out the fact that this working group is in a little bit of a difficult spot because there's already legislation that points at the protocol that we're modifying for robots.txt. And that makes it makes the impact of this document, in my opinion, kind of exceed, our mandate and scope, which I think that a lot of the earlier suggestions about this about this section, including my my previous proposal with the exclusions, we're rightfully pointing out that that was, too far too far outside the scope. However, I think because of the, the impact and the way it differs in different jurisdictions, we really need to make it clear, what the limitations of this, of this specification are. And then my ask for people would be, as you formulate arguments against the proposed text, please include reasons that are directly related to the proposed text. Also, please consider whether the argument against is as effective, of an argument for the text. And if if the same argument can be effective for both for and against, I would posit that it's not meaningful. And then just to repeat, please try to restrict criticisms to what is actually in the text, without adding, meaning. So I, as far as the text goes, I think we worked really hard to try to pare it down so that it didn't didn't exceed the scope, didn't try to legislate, but really tried to provide a clear picture of the limitations of this vocabulary definition to try to avoid confusion, misunderstanding, and to ensure that it can't be interpreted as an extension of legislation, but is, you know, just a protocol, just a a definition.
[00:13:21] Suresh Krishnan: Thank you. Thank you to Mitrobot. Does anybody in the room or in MeetEco have any further comments? Also note, Sebastian suggested some text that Martin echoed on the chat. And yeah. Glenn?
[00:13:45] Glenn Dean: Glenn Dean, Comcast, NBCUniversal. I really don't like the notion that we consider legislation or not legislation as part of our criteria. The IETF does not write legislation nor are we influenced directly by legislation. We work on stuff that the community comes together and agrees on. Legislation can evolve to change what based upon what the community creates, and likewise, the landscape can evolve. So we should do what we think is right. That said, the language proposed by Sebastian on the list, I think, is actually really good. And I would like to say my I support it, and I'd like to see that that gets pulled in and replace is the pull request that is currently before us.
[00:14:31] Mark Nottingham: So, Glenn, I'm stay at the mic for a second. You said replace the pull request in entirety?
[00:14:37] Glenn Dean: No. Like, the the very last line. It it it's the very last line that's
[00:14:40] Mark Nottingham: causing Please be precise. Okay.
[00:14:42] Glenn Dean: Yes. So thank you for the clarification, Mark.
[00:14:44] Mark Nottingham: Thank you. Okay. What is the mischief of the last line? Sorry? What what what what's your objection to the last line? Can you can you describe that?
[00:14:54] Glenn Dean: So I I as I've said extensively on lists, I I think that the various different versions that have been proposed for the last thing, including the stuff here, are dragging us into a territory around policy discussions and other aspects that we're not quite prepared to deal with as as an ITF working group. And I think it's a it's a can of worms that we rightfully early on said we were gonna try to dodge and avoid by not dealing with them. Things like copyright and other stuff.
[00:15:28] Mark Nottingham: Okay.
[00:15:29] Glenn Dean: And so I think that Sebastian's text does a nice job of threading that needle in a in a constructive way without, you know because the alternative is say nothing. That was my original proposal, say nothing. But I'm convinced that I can live with Sebastian's text. If that's helpful. So hopefully.
[00:15:50] Mark Nottingham: So the the PR that the I think the relevant line we're talking about, lines two eleven, two twelve, two thirteen. Because of this, stakeholders need to decide when and how to follow or not follow preferences in the context of legal, institutional, ethical, or other interests and commitments. Correct? That that's the one you're objecting to? Yes. Okay. And is it just the mere the mere mention of things that, you know, that might impinge upon a decision?
[00:16:25] Glenn Dean: Demir mentioned. It's when it's taken together, I think that it opens like I said, I think it opens a can of worms that if we wanted to go there, we could. I think we'd have to bring a lot of other parties in to have the conversation about what those particular qualifications that are in that, as you quoted, create door openings that people would take and say, well, this means that and this means this other thing. The simpler way is to not say things that are gonna create potential downstream conversations and confusions that will be misinterpreted or taken. I guess what I'm trying to ultimately say is people will cherry pick k. To use the term from sports.
[00:17:07] Mark Nottingham: So I'm sorry. I didn't hear that.
[00:17:08] Glenn Dean: People will cherry pick the words that right. And so that's what I I fear the current, as you read, would suggest it. I think Sebastian's words provide similar ideas, but don't open up the doorways for the cherry picking possibilities that I fear. So
[00:17:27] Mark Nottingham: because I think in an ITF context, the way that I think about this text is effectively, it's an applicability note. It's saying, just so you're aware, this is how this will work in the real world. And and it's it's I guess I'm just having a little trouble, how this opens a portal to that those kinds of outcomes when it's it's you know, if if we're not
[00:17:48] Glenn Dean: Well, specific realizing that it takes. Legal and ethical are are interesting interesting declarations.
[00:17:53] Mark Nottingham: Legal and ethical are the real triggers here. Okay.
[00:17:58] Glenn Dean: And and I know that on this, there was also discussion of language that potentially cited specifically the public interest. And I believe we've had previous poll requests that had public interest specific specifically cited. Again, that create create conflict, especially since we don't have a process for clearly defining what that is in the context of our specification. K.
[00:18:19] Mark Nottingham: And You're not gonna let
[00:18:20] Glenn Dean: me go sit down, are you?
[00:18:22] Mark Nottingham: No. No. No. No. You're you're there. I I think in in my mind, when I think about this, the question is if if we're gonna replace that text, will it sir still serve that purpose of giving those headlights that these are just preferences and that there are other considerations and so forth. So I'm I'm just gonna read Sebastian's text, which I need to find. Where did it go in this thread? Can you put it
[00:18:51] Timid robot: on the screen? Also in the chat.
[00:18:56] Glenn Dean: I must say, I cannot read what is on the screen in
[00:18:58] Mark Nottingham: the Yeah.
[00:18:59] Glenn Dean: It's big I just can't. Yeah.
[00:19:00] Mark Nottingham: So I found it. The the proposal is to replace that text with because of this, stakeholders and stakeholders itself is a loaded word, but we can get there later on. Because of this, stakeholders need to decide when and how to follow or not follow preferences in the context of legal, institutional, ethical, or other interests and commitments. Oh, no. Sorry. That's what he has. Yeah. The other one. There it is. An entity that receives usage preferences has a choice whether to follow those preferences. This specification does not determine how that choice is made, whether and under which circumstances a preference is followed is outside the scope of this specification. So that that that would be your preference.
[00:19:45] Glenn Dean: This would be my if we're gonna include something, this would be my preference to include. My my first preference is to include nothing, but I can live with this.
[00:19:53] Mark Nottingham: Okay. So let let's it seems like this is the only contested part of the PR, so let's focus on this. Any other commentary? Any reactions to that? The queues are very empty right now.
[00:20:09] Suresh Krishnan: There is people on the queue.
[00:20:11] Mark Nottingham: Oh, there are. Okay. I see timid. I yeah. I can't
[00:20:14] Suresh Krishnan: Martin, did you wanna say something, or did is it already called by the Sebastian?
[00:20:18] Mark Nottingham: Go ahead, Martin. Oh, timid, did you want to
[00:20:27] Suresh Krishnan: We got timid robot because they can say what they wanted to say, like, so but
[00:20:32] Timid robot: So I just wanted to say, I largely agree agree with Glenn, and I'm I'm happy that we've, you know, that we we've cut out the text that that Glenn mentioned. But I think that where we differ is that I think we can be we can be more helpful within the kind of turbulent troubled context that this document is going to land in. And it's my opinion that the the, the proposed text and and calling out those specific terms provides, more help, to users, of this document, than the suggested replacement text. I also would say that the suggested replacement text, I'm I'm pleased to learn that that's only applies to the last sentence. I I misunderstood and thought it applied to the whole thing. I I think it's okay, but, in my opinion, inferior to the proposed text. Thank you.
[00:21:43] Mark Nottingham: So, timid robot, if I could characterize, you have a preference for the current PR text, but you can live with replacing it.
[00:21:51] Timid robot: That is correct.
[00:21:52] Suresh Krishnan: Thank you.
[00:21:55] Martin Thompson: So, Martin Thompson, I was really hoping you would stop with the back and forth with Glenn and and let the drain the mic queue.
[00:22:03] Mark Nottingham: We don't get everything we hope for.
[00:22:04] Martin Thompson: Yeah. Yeah. So I have no particular opinion because I'm just holding the pen here, but I did I did also put another one up that I think is a little shorter than what Sebastian suggested. It simply replaces the last two sentences of Sebastian's with what I can't see now because I don't have it in front of me, but external factors may influence that decision. But that decision is outside the scope of the specification.
[00:22:32] Mark Nottingham: Where have you put this?
[00:22:33] Martin Thompson: Scroll up. Both of them are suggestions now. They're concrete. Oh, I see. So that's that's just shorter again.
[00:22:42] Suresh Krishnan: Do you want me to show both, Martin?
[00:22:44] Martin Thompson: I don't know how you would do that because you don't have enough screen real estate, and the text is very small now. But, yes, I suggest people who have the ability to watch along on their own screen can can make a decision here.
[00:23:00] Tom: So I'll read that.
[00:23:02] Martin Thompson: I suggest that we're we're kinda getting to the point where my sense is that people have preferences but not strongly held, and that the general direction is looking pretty good. I don't know if that that's your read on the situation, but I'll see what others have to say. Because Nate is after me.
[00:23:20] Mark Nottingham: Well, I'm I'm hearing a lot more nuance in the room here than we have seen on the mailing list, which I appreciate.
[00:23:30] Nate: So I was part of the small group that came up with this, and I'm of the opinion that any of the the proposals that we have are good if they move the the entire sort of effort forward. Sebastian's Martin, I think, has has really tight text. I will say that there are some people from that small group who I don't see here. They may be joining online, but I think it's important that we make sure that we get their input in addition to to timid robots. But it sounds like we are getting to a place where at least the first two parts of this, we have some sort of agreement around. The idea there was is, like, the first part of the the whole proposal was, let's just say what we do very clearly, which is this is a way to express preferences that can be interoperably understood. Then let's say what this doesn't do, and that's the listed of bullets. It sounds like those two first two parts really don't have a lot of objections, so I I feel like that's really good that we've made a lot of progress on that. It's just this last part. The point of that is is trying to give some sort of a just help the the Internet community understand what it is that that they have with these new preferences that we're making. And I know that there's been a lot of sort of statements about what the what is and is inappropriate for the IETF. I'm new here, so I'm not an expert on this. I will say I went back and I read the RFC that originally made robots, and that RFC does have some sort of language that sort of says stuff around like, hey. This isn't a substitute for a content security policy. So clearly, in other contexts that that, you know, particularly for bigger RFCs, this has been considered. Whatever gets us to consensus, and I'm happy to continue to work. I've I've talked with people on kind of both sides of this issue through this whole thing. I'm happy to continue to work with whoever we need to to get this done and move on to the other topics. Thank
[00:25:14] Mark Nottingham: you, Nate.
[00:25:16] Suresh Krishnan: Queue? Miria. Yeah.
[00:25:20] Mirja Kühlewind: Miria Kühlewind. I think the the reason why we're discussing this is because what got lost a little bit in this text is that there's actually no expectation that everybody will always follow these preferences, and not following the preferences is not misbehavior. There's good reasons for it. That got a little bit lost in this new proposed text, I think. And on the same lines, actually, if you look at the can you show the PR, the start of the PR again?
[00:25:50] Suresh Krishnan: Original PR, Maria?
[00:25:52] Mirja Kühlewind: Yes. Yes. So the first bullet point here says, if you read it, this specification should readers of the specification should understand that it does not provide for enforcement of these preferences. You could imply by this that there should be an enforcement, but we are not just not providing it, but we all think there should be. It's just not in the specification, which is also kind of the same lines that you would rather wanna say this is not intended to be a basis for enforcement at all or something like that. You look confused.
[00:26:33] Suresh Krishnan: I am. I think the audio is terrible. I'm not sure I appreciate, like
[00:26:39] Mark Nottingham: I I I yeah. I think if you wanna make a proposal there, maybe on the PR, but I I I think that that might open new territory where there's disagreement. So I don't know that it it it's gonna help.
[00:26:54] Mirja Kühlewind: So I do believe that we are agreeing that we are not designing this as a basis for enforcement mechanism.
[00:27:01] Mark Nottingham: No. Our charter constrains us from working on enforcement. That's a no. But that's a different thing.
[00:27:06] Mirja Kühlewind: But by just saying this specification doesn't provide an enforcement mechanism
[00:27:11] Mark Nottingham: Please.
[00:27:12] Suresh Krishnan: You So so, Miria, that that is the text that's proposed to be removed. So this is what you're pointing to. Right? It's gonna be gone.
[00:27:19] Mirja Kühlewind: No. No. The first bullet point in the green Here?
[00:27:22] Kevin: There. No. Yeah.
[00:27:23] Mark Nottingham: Here. This one's new text. Yeah.
[00:27:26] Mirja Kühlewind: This might imply that there should be an enforcement mechanism. We're just not providing it in this spec. I think it's an editorial thing, but I think this is this is the whole problem about the PR that it really doesn't say clearly that it's actually, there are valid behaviors where you would ignore the preferences, and this is not a misconduct.
[00:27:47] Suresh Krishnan: Thank you, Maria. I'll let Glenn go, but I do have a comment after.
[00:27:50] Mark Nottingham: I I
[00:27:51] Timid robot: just wanna interject
[00:27:51] Mark Nottingham: there real quick. I I don't think we wanna get into the business of of defining good or bad contact at all. That that's not why we're here. Yeah.
[00:28:02] Mirja Kühlewind: Absolutely not. But the thing that you're saying there could be a good reason to ignore it, and not only because you're you're a bad actor, you're ignoring it, that is lost.
[00:28:14] Glenn Dean: So so, Mirja, stay at the microphone because my question is actually sort of for your comment. You may wanna respond to it. I'm confused by the by the comment about wanting to add language about not having an enforcement mechanism. Let me ask this question. If an implementer takes this this spec, puts into some technology platform, and in that, they implement an enforcement mechanism around it. This spec does not specify an enforcement mechanism, but the implementer does add that as a extra feature. What does your language what is your objective of adding that language in mean in that situation?
[00:29:02] Mirja Kühlewind: So I think we should just slightly rephrase this first bullet point. That's all I'm saying. And the difference is I'm not saying you couldn't do an enforcement, but I'm saying this wasn't designed as an as something that is meant to be in an enforcement mechanism. While this language could imply that it was designed for an enforcement, we're just not specifying it here.
[00:29:24] Glenn Dean: Okay. So okay. So so you're not you're not prohibiting with it. You're merely just redeclaring what's already in the charter saying the charter of the group isn't doing enforcement mechanism. Okay.
[00:29:35] Mark Nottingham: I I think, yeah, there could be ways that that could be helpful. But may maybe we can just try and get the consensus on this. And then if you have a modification to to clarify, we can do that as a separate proposal. Yeah. Okay. Anyone else in the queue? Ecker.
[00:29:59] Eric Rescorla: Yeah. I think this text is good. I think it strikes the right balance. I think that the the import the Sorry.
[00:30:04] Mirja Kühlewind: Sorry, Ecker.
[00:30:04] Mark Nottingham: Could you clarify this meaning which?
[00:30:09] Eric Rescorla: Sorry. The Martin's post text Okay. Which I I I know is actually other people's post text. I think the important thing to convey here is that from our perspective is what is what conformance with specification means. And what conformance specification means is that you properly parse things and then do things with do whatever you please with them. That's what, of course, the specification means. And everything else is, like, not in our remit.
[00:30:35] Mark Nottingham: Okay. Okay. We seem to be converging on Martin's proposal or a form of it. Any further thoughts on that or anyone have a deep issue with that? I think what we might do is take it to the list and iterate iterate a bit. But it it sounds like it's it's we're we're converging on a mature proposal for for resolving this issue. And and if we do, I think we'll have a chat, but we might even wanna consider a a formal consensus call around it once once people have a chance to review the text and yeah.
[00:31:12] Kevin: I don't We have a
[00:31:14] Suresh Krishnan: I do not know what is happening in the sharing, but let me stop sharing and do it.
[00:31:18] Mark Nottingham: But we do have Sebastian? Sebastian in queue.
[00:31:21] Sebastian: Yeah. Just comparing Martin's suggestion or improvement of the proposal. I think the difference between one and the other is that the the language that I try to find is, like, where the specification is actually the starting point. So, like, the second sentence, this specification does not determine how that is made in comparison to, like, external factors could influence that decision. I think the the difference is mainly, like, that this proposal, this draft should always have the specification as the starting point and then go to the outside, whereas the revised version, which I don't, in principle, disagree with, starts with external factors that have an impact on the specification. Does that make sense, what I tried to say? So I I yep. I prefer the the proposed initially proposed version to to Martin's. But as I said, this is not a very strong opinion.
[00:32:29] Mark Nottingham: It sounds like we're getting towards editorial aspects of it, which is making me comfortable. I'm not hearing fundamental issues being raised anymore. Although, I I do note that, you know, we do have a lot of people who are not in the room. I'm not entirely sure that everyone, all the other perspectives are are represented remotely, so I think it's probably good to go to the list at this point. Yeah. Any further comment on this one? Anyone remote?
[00:33:01] Suresh Krishnan: Nobody in the queue.
[00:33:03] Mark Nottingham: Okay.
[00:33:05] Suresh Krishnan: Martin, is this something you wanna do real time and use a couple of minutes to do something, or do you wanna kind of to show up, or we can do it nonetheless, like Mark said?
[00:33:15] Mark Nottingham: Continue. Okay. Okay. Why don't you open up Kevin's PR next? Yeah. So, after at the Toronto meeting, we we had some discussion about the, training term, draft-ietf-aipref-vocab, I believe this is about. And, Kevin had some some thoughts about it. Do you wanna come up and and kinda give a quick overview of of where this is at? It's all the way down here.
[00:34:04] Kevin: Yeah. So like like Mark mentioned, my homework assignment from Toronto was to take some of the discussion in the room there and put this together. I think there's already been a fairly substantive discussion on the list, so there were two pieces of feedback there. Two I those two that I recall were that, the phrase common parameters was a little bit confusing to people. I think the best option I saw on the list was learned parameters. So these are not hyperparameters or other architectural things. They're the the weights and biases and other things that are modified during the training process. And I had had originally had a phrase that is used or made available to use. And that was trying to address some of the concerns, that the publishers in the in the room in Toronto had brought up. And not to put words in their mouth, but my understanding of that concern was that they wanted to make sure that there weren't ways to sort of that once a model trained on data that had preferences attached, that that state attached. There were not ways to work around the preferences. I think the discussion on the list convinced me that that's something that can be handled at attachment time. Right? That whatever attachment mechanisms we put together might have a mechanism for for ensuring that preferences stay with a model or something like that. And so I pulled that phrase out of this draft.
[00:35:56] Mark Nottingham: And you have a proposal from Leonard here to remove the word synthetic. Is that you consider that a friendly amendment?
[00:36:04] Kevin: I think that the word synthetic is doing some lifting there. This is intended sort of to be a nod at, some of the ideas that Brad Silver raised. Right? We're talking about content the model has produced that is substitutive in some sense without using that word because that word started some food fights. So I think that the definition is much stronger with synthetic content in there.
[00:36:46] Suresh Krishnan: Okay. Nate, if you wanna use the other mic. Or Kevin, you can come up here and give the mic to Nate. I actually wanna ask a question.
[00:36:54] Nate: Could you just give us a, like, brief explanation of sort of why we're proposing this as opposed to the the previous version? Like, what what what the differences are and, like, why you feel that this is important?
[00:37:12] Kevin: These were supposed to be really rather small adjustments. Right? There's not not supposed to be any massive substantive difference. I think if you scroll up, I briefly said something about each of the word choices and stuff. That will probably be
[00:37:27] Mark Nottingham: better than my
[00:37:28] Kevin: memory at this point in the week.
[00:37:34] Mark Nottingham: Probably easier for me to to read it out. The most substantive change I'm proposing in this PR is that we move from talking about a model that can generate to one that is used or made available for use to generate. One of the things I heard most clearly in Toronto from people thinking about declaring preferences was concerned about the subjectivity of definitions based on purpose and intent and about the possibility that either might change over time. This makes the category slightly more narrow but also more objective. Something either was used or wasn't, much less is subject to interpretation. The same property showed that implementers apply the category consistently too. I've expanded used to used or made available for use in an attempt to address concerns. And you've you've evolved it since I think you wrote this initial text, haven't you? That was interesting.
[00:38:29] Eric Rescorla: Yeah. Made available is gone.
[00:38:31] Mark Nottingham: Sorry, Edgar?
[00:38:33] Eric Rescorla: I said, yeah. Made available is gone. It's not in the text.
[00:38:37] Mark Nottingham: Yeah. Alright. Let's, let's go to the queue. Edgar.
[00:38:45] Eric Rescorla: Yeah. I think this text is generally good. Kevin, I wanna push in this synthetic question a little bit to make sure I understand it. Can you give me an example of a of a case in which a model will be used to generate content, but that content was not synthetic content?
[00:39:03] Kevin: I think it's there. It's it's there. I got
[00:39:05] Martin Duke: the mic.
[00:39:05] Suresh Krishnan: Kevin, you can come up here if you want.
[00:39:08] Mark Nottingham: The
[00:39:11] Suresh Krishnan: pink x. You can use the pink x. Kevin, there's a pink x here. You can stand there so the camera gets
[00:39:18] Mark Nottingham: you.
[00:39:21] Kevin: That's a great question, Ecker. No. Although one certainly, I guess, in theory, could train such a model. I think it's there just for sort of in order to be abundantly clear what we're talking about.
[00:39:39] Eric Rescorla: I don't have a problem with it. I just wanna make sure it's not doing something that I don't like.
[00:39:43] Kevin: Yeah. There's not something subtle that you might be missing.
[00:39:47] Eric Rescorla: I'm not gonna fight one way the other for synthetic. Thank you. I just asked as good.
[00:39:54] Mark Nottingham: Forest? Sorry. Forest? Yeah.
[00:39:58] Farzaneh Badiei: Hi, everybody. So I, I raised concerns with the changes that were made, after Toronto meeting to the AI training definition. I think that it's made the the changes made the category broader, and I think that Kevin changes mostly address those issues that I had in mind. There are, like but I have to look into this more because this well, we it's good that we removed, made available to use. But I think that we have to also, like, look into the term use here. But in general, I'm cautiously optimistic that we can go we can see what we can we can support this language. Thanks.
[00:40:55] Mark Nottingham: Okay. So it sounds like it's an improvement in your eyes. Thank you. Martin Duke.
[00:41:00] Martin Duke: Yes. Martin Duke from Google. Definitely a tourist here, but I mean, it's an advantage in this case about the word synthetic. Just as a person who knows nothing about this, I would take synthetic to mean if you include the word synthetic, I would take that to mean, as a naive reader of this, that I could not take your photo of the Colosseum on your website and then use to generate an image of me in the Colosseum, but I could absolutely serve up a photo of the Colosseum if a user asked me for a photo of the Colosseum. So if that's your intent, then I think synthetic is a good word to include. If it's not, then maybe not. Thanks.
[00:41:41] Mark Nottingham: And, well, that's interesting because these are AI preferences, not general use preferences. So, yeah, there's a weird line there. But I I don't
[00:41:52] Martin Duke: know anything
[00:41:52] Mark Nottingham: else about it. Okay. Fair enough. Fair enough. Nate.
[00:41:56] Nate: So I I'm still formulating opinion on this, but I think my concern is around the replacement of production or refinement with to modify the learned parameters. I think production refinement is much more clear to a average person about what what this means when you think about the websites that are gonna try to figure out, you know, how to express or not express a preference. I also think, like, learned parameters, like, I I would like to dig in, maybe hear from Kevin what what you mean by that. For me, personally, I don't actually agree that these systems learn. I think learning is a loaded word. Humans learn from experience. And I and I think that, like, I I what does it mean to learn in this sense? If you're if we're just using, a machine learning definition, like, I like I I don't know. I I I I'm I feel like that's it becomes, like, sort of technically loaded in a way that makes it less accessible to average people, and I'm also not I I I'm just curious about what the difference is between production of refinement versus the learned parameters.
[00:43:00] Suresh Krishnan: You wanna take it? Yeah. I'll address that.
[00:43:04] Kevin: I think both great points. Thank you for raising them. As you are producing or refining a model, what you are doing is modifying the learned parameters. Maybe you and I can work together on some informative language that would sit next to this and make that clear. I think other than that I am a big nerd, the reason why why I've chosen sort of very precise language is just because, it's very important to me that that we all understand what a definition we come to consensus on means, and that there not be wiggle room around it.
[00:43:44] Suresh Krishnan: On
[00:43:47] Kevin: the learned parameters question, which I think was your other other one, that's just all the stuff that changes during the during the training process.
[00:43:56] Nate: So when does that end? Like, is it, like, with the weights or, like, what like, how would you explain where that ends? Because I'm also thinking forward to the to the inference discussion that we'll have feature. Like, what's the what's the line there?
[00:44:10] Kevin: Right. So weights are a type of learned parameter. Right? And in fact, in common parlance, including internally at Anthropic, right, we just say weights. So those are sort of the same thing. But at some point, you stop modifying those learned parameters and you start sampling from the model. You start performing inference on it. And things that you, for example, put in the context window of of a model at inference time, produce output tokens, but you're not modifying the learned parameters of the model. Like, when the next person comes along and has a conversation with the same model, the thing you put in the context window in that other conversation doesn't affect the second conversation. That make sense?
[00:45:06] Nate: Yeah. That makes sense. And I I think that, potentially, this is helpful then because I I I think it's important that we wherever this category ends, there's, a bright line, and then the inference category sort of carries it forward. So it sounds like this is is done with that thought in mind, so we can connect and and chat further, but I I appreciate that.
[00:45:22] Mark Nottingham: Right. And also, you know, we need to remember we have a definition section, and maybe we should develop that as well. Yeah. Clint.
[00:45:31] Glenn Dean: So let me start by saying I'd like the inclusion of specific language. I think that helps. And I and I was gonna Mark jump got me to it faster. We should include specific stuff in our terminology section that because these are very specific terms of art, and so we should have an agreed upon definition of them. That said, I think we also have to word things in such a way that this specification continues to be relevant and not needing updating when the terms of art get slightly modified in eighteen months because we've got some researchers that come in from the that aren't here today that come in with a new tweak to it. And so sometimes you can do that by specifying in this in the definition sections, the terms of art, put the terms of art in the body like you're doing today, but also attempt to put some explanatory text as to what the goal is of including them. And that way, when future things come in from left field that are slight modifications, this document has a longer life than simply being adherent to very specific narrow terms. So it's a suggestion.
[00:46:44] Kevin: I think it's a great one. Do you think that something like the explanation I tried to give in the PR description and the conversation Nate and I just had, that sort of language would be do you think that would
[00:46:59] Glenn Dean: It's a start. I I I mean, I myself would describe this as we're discussing about direct training of against original content versus model to model based training through either model weights being exchanged or synthetic data being generated by the model then trained against. So that's the way I explain it, but I realize I'm a technology nerd, and not everybody might describe it in those same terms.
[00:47:25] Kevin: Okay. Thank you.
[00:47:27] Suresh Krishnan: Thanks. Edgar?
[00:47:29] Eric Rescorla: So the explanation you just gave, Kevin, I I definitely understand the distinction between modifying the weights and what goes in the context window. But let me give you a hypothetical, which is say that what I decide is the way I'm gonna build my system is that every morning, I'm gonna scrape the New York Times, and I'm gonna put that in the as the first, you know, 100,000 tokens in the context window for every single piece of inference that happens the next day. Is that we covered under this or not?
[00:48:01] Kevin: I mean, it's it's a little bit hard to think through a relatively contrived hypothetical. There are lots of reasons why you wouldn't want to do that. But I suppose under this definition, that would would not count as modifying the parameters of the model.
[00:48:21] Eric Rescorla: I think so too. I I I I I know it's contrived, but, you know, how the hypotheticals are they push they push the boundaries of things. I guess, I'm not sure I'm bothered by this, but I just wanna make sure that, like, I wanna make sure people understand what the what the boundaries of what we're trying to write here are. And if someone if there's a less contrived version that people will be bothered by, then, perhaps, then then perhaps, they might they might think about that.
[00:48:47] Kevin: So That that that seems like, in effect, a degenerate case of RAG. Right?
[00:48:53] Eric Rescorla: Yeah. I I that that that that's true.
[00:48:56] Kevin: And that's something that we've we've discussed quite a bit in the in our inference time use conversations and I imagine we will get back to you shortly.
[00:49:07] Eric Rescorla: Yeah. So maybe it's
[00:49:08] Mark Nottingham: fine. Okay. Well, yeah. The queue's empty. Any any other comment on this? So I think, thank you,
[00:49:20] Kevin: Kevin. Of course.
[00:49:21] Mark Nottingham: Both for this and the previous item, let's try to focus on these two aspects on the mailing list in the near midterm future, so we can try and get these nailed down. I think they're both productive conversations that are almost to the point where we can be confident we're in a pretty good place. So let let's focus on those, I think, on the mailing list. The other thing that that comes to mind is, you know, the the the one thing we've heard people, express a a a desire for is this this inference term, which we just referred to. We've had a number of different proposals for that in the past. Actually, if you go to the wiki tab on the yeah. Oh, yeah. I hate that. Yeah. I know. You can't click on the v neck. Oh, yeah. And you click on use proposals there. Yeah. That's the one. So if you scroll through this page, I've I've tried to record all of the the major proposals for some sort of use or or inference term that we've had over the the the lifetime of the group. And there are a fair number of them. So if we want to, we can try and talk through some of these today. The you know, we can certainly we haven't declared consensus not to do any of these. It's just we we haven't yet found that that they're productive starting points for for discussions, or we've had some false starts, I should say, on some of them. So if if we want to either have new proposals, which we've we've, you know, continually been asking for, or we wanna try and revisit and refine these, I think, is is up to the group. You know, we're we're not I I think it it we're not at a point where we're going to finish in the next couple of weeks, so we still have time for these discussions. But if if we finish all of our other work, then we will be at a point where we have to make some potentially hard decisions. So the this I I guess this is all around about way of saying that the sooner we get proposals, whether they be brand new ones or refinements of these, the sooner we can start those discussions and and and try to make some progress on them. Does anyone have any kind of proposals in this space or or thoughts about the existing proposals just so, you know, raise awareness of of your efforts or or if you wanna try and work with other folks? I know people have talked about working together in the past. Nate, you you seem yeah.
[00:51:47] Nate: So at the very end of Toronto, I wrote a proposal in a comment on January, that has not gotten a lot of discussion at all. But I I wanna just briefly explain why I think that approach, if maybe it's not those exact words, is the right approach. My proposal was to take what is currently the training definition before we get to Kevin's proposal, and to just basically carry it forward. To just say, you know, whatever we define as the stopping point for the training definition, then all tokens beyond that, like, all use beyond that should there it should be possible to express a preference as to use beyond that. So my proposed definition is AI inference, the act of using an asset for inference by an AI model that can generate content in one or more modalities, text, image, audio. Inference means all use beyond the production or refinement of an AI model. And we went with Kevin's proposal.
[00:52:42] Suresh Krishnan: Am am I pointing at the right thing,
[00:52:44] Kevin: that you're
[00:52:44] Suresh Krishnan: like, it's one seventy two
[00:52:46] Nate: Yeah. Yeah. Yeah. It's the
[00:52:47] Glenn Dean: it's I
[00:52:48] Suresh Krishnan: have it on the screen.
[00:52:48] Nate: Yeah. It's the quoted text there
[00:52:50] Suresh Krishnan: Oh.
[00:52:51] Nate: In the middle. And if instead we go with Kevin's proposal, then I would just take the same approach, and I would just say, you know, everything beyond the learned parameters. We'd have to come up with something. But the idea is what matters, which is that most of the work that we've done about what counts as AI and what doesn't count as AI, we've already had these debates with the training definition. I think the inference discussion could be really quick if we just decide. When we say that, you know, by AI, we mean generative AI systems or whatever we mean by that. It should be possible to set also express a preference for use of content by those systems. And and that's really all all we need to do. Like, we don't need to try to go in and define every single possible category of use. If if I can express a preference as to whether or not my content is used to train an AI model, I should also be able to express a preference as to whether or not that trained AI model can use my content. And I think that's the the sort of structure that we should take. And then wherever we land on the training, I think something like this sort of is the most logical category forward. And then as we think to the future about composability or adding additional categories or things like that, you know, if you look at, like, the search, definition, I know we don't have a hierarchy anymore, but it basically functions as an exception to the other two definitions. So if there are future categories of use that we feel in the future, you know, are are really important for people to be able able to express some differential preference, then in the future, you could add those on, but we would start with the ability to express a preference as to all use by the the category of systems that we have. I feel like this is taxonomically correct. I think it's it's important to avoid a position where there's like exploitate you you know, actors can exploit what is and isn't with if we only have certain definitions of use. And so this will need to adapt to whatever the training definition is, but that's the basic idea. Wherever training stops, whatever, you know, whatever that category models is, all used by those models should be expressible as a preference.
[00:55:00] Suresh Krishnan: Thank you.
[00:55:00] Mark Nottingham: And I I do see some nodding heads in the room, so that that's good information. Paul? Timid robot. Oh, I'm sorry. I'm sorry. My eyes. Timid.
[00:55:10] Timid robot: Timid robot. I just wanted to repeat my, what I thought was an moment for me from Toronto, which I I credit to Martin, but maybe I misunderstood him. And that the difficulty in a lot of these is figuring out where, like, where to make a line between them and how to define that line, so that there's no overlap. And I thought I heard Martin say that those that fuzziness can be mitigated by simply stating what happens if two categories are perceived overlap in the category definitions themselves. I personally think that that's a strategy that makes this work much easier. Thank you.
[00:55:57] Mark Nottingham: Thank you, Tim and Robot. Paul?
[00:56:02] Speaker 1: Yeah. I think what Nate proposed makes a lot
[00:56:07] Sebastian: of
[00:56:07] Speaker 1: sense, but what Nate proposed is also essentially a rewording of the very first attempt that we made at this, like, on the wiki where you showed AI use, which was essentially saying the act of using one or more models as input to train the AI models as part of the operation of that model. Sort of functionally the same, like, more elegant language. And the thing why we couldn't agree on that in, ironically, London last time, so we'll go back and have this discussion in London again, was that I think there are fundamental difference in opinion in who is making what there's two different scenarios who is using the content. Right? Like, the one thing is the AI model uses it when and I think the idea is when when models reach out in response to a user's prompt or some other input and obtain assets where it's clear that the the entity using is the model. Or if you don't wanna ascribe something to the models and if the the company or or the entity operating the model versus if a user provides something to the model, then the question arises. So, like, I upload a PDF or an image into that thing. Who's actually using this? Is that me or the model or the entity operating the model? And I think on that second part, sort of, like, there is quite some difference of opinion in how far sort of these these these preferences should reach into governing individual users' behavior. And so I think while while generally Nate's approach is is promising, we probably need to account for these two different entity or types of entities making use by maybe making them separately addressable because we know some people want to include this, and we know some people want to exclude this. And so we probably need to be able to separate these two scenarios.
[00:58:15] Mark Nottingham: Thank you, Paul. Nate.
[00:58:24] Nate: So to address Paul's point, I think yeah. One way to do that is to have either two versions of this category, one for use by users, one for use by automated systems. Another would be to have a sort of user provided category that functions similarly to the search category in this if if we feel like some asset owners might have a separate preference for users. I think either of those approaches is totally fine and very manageable given this structure. The only thing I I really would not wanna have is a system where we decide that, like, there's not an ability to express a preference as to content that's uploaded by users. We had, you know, I I've I've mentioned this before, but there was a major incident about a year ago where a major AI model was used by a bunch of users with a viral viral trend to, quote, put her in a bikini to take photos of people online and to to bikinify them. And I think, you know, that's a one very strong example of why asset owners might have a preference even in the case of user private user provided assets to not have their assets, contributed to AI. And so as long as it's possible to express a preference on that, I think it's fine to have a separate category or or to have some method of of making that distinction.
[00:59:46] Mark Nottingham: Faris?
[00:59:51] Farzaneh Badiei: Yeah. I just I want to disagree with everything that was just said. We are not here to do a content moderation, and we have been discussing this. And a few times, this has been brought up. The cons the concept of in inference and the implications that can happen for the end user and also the open source developers and people who provide their own they create their own AI models. They can be, like, small entities. They can be NGOs. They will be very much affected. And we have written there is an Internet draft that talks about the impact of the impact on the end user if these preferences are too broad or affect different, like, different functionalities such as translation services, accessibility features. So all in all, if we want to talk about the inference if we want to talk about the the inference and we need to, first of all, talk about, like, all the concerns that were raised before. And and and then we can discuss what we can do in the future with the definition. And I think the user, like, the user who uploads and stuff and the consumer should be out of the discussion. Thank you.
[01:01:40] Glenn Dean: Ecker.
[01:01:43] Eric Rescorla: I mean, just as a practical matter, the user provided content isn't gonna work. Because, like, because, like, even if there are preferences attached to it, the user can just strip them. So, like so, I mean, maybe there's some case where user, like, gives you a URL and you go there. But, like, I mean, it's a concrete matter. Like, this is not a very effective thing. So I think trying to, like, come in on the situation where, like, like, where you're where effectively you're asking the system to mechanically enforce, like, the the user price content that doesn't work with it, think, is not here effective. So I'm I'm not that jazzed about trying to work worry about that case.
[01:02:23] Mark Nottingham: Nate? Oh, okay. That's an old hand. Any other discussion?
[01:02:30] Suresh Krishnan: Yeah. Miria, if I can make a point here, I think we discussed it, and I don't think we got anywhere. So okay. So Miria said, just to make sure I understand correctly, does this preference equally apply if the AI directly catches the content or if the user catches the content and feeds it through its prompt to the AI. I think I don't think we had a really good feel of how the AI agents go and ask for content. I I think, like, I've seen a presentation somewhere in the ITF about, like, how somebody identifies themselves, the identify themselves with the UA or as an agent or not. So I don't think it's in scope for us to decide. But if you have different thoughts, come compensate. But I think it's not relevant for us here.
[01:03:18] Mirja Kühlewind: I think then you're saying it would potentially apply to both. Right? It's not like we are separating them out.
[01:03:30] Mark Nottingham: I mean, it it seems like we have the potential to define a term that covers the, and I'm rapidly hand waving here, autonomously fetched use time content, that is not user supplied either directly as content or as a URL or whatever. And so we might make progress on that. It sounds like the the really contentious part is that latter thing. So so perhaps we could try, around the London time frame to at least make progress on the the the uncontroversial part and then also discuss the controversy, but not necessarily link them. Now the eventual mechanism we provide might link them, but that could be TBD, if that makes sense.
[01:04:19] Mirja Kühlewind: I just wanna say I think that if it could apply to both of these situations, I think that makes the category very broad. I'm not sure if there's a way to get something more narrow, but it makes it very broad.
[01:04:32] Mark Nottingham: Certainly, having an existence proof of, you know, the narrowing that that would be successful would be an interesting thing. We have timid robot in queue.
[01:04:46] Timid robot: Oh, I think this is timid robot. I think I think I heard Ecker say that there wasn't it wasn't realistic to think that a user would encounter these preferences if it was specific to user supplied content, in a in a inference context. And my recollection is that Leonard, provided lots of examples of of just that, just that use case where the UX would make those preferences available to the user or, potentially, if it was, an a file attachment, refuse, you know, depending on the the software software maker's decision, you know, refuse to move forward based on a preference. I also wanna give a plus one to Nate's idea that we should be able to express a preference for all you know, like, the entire scope of of AI usage and that I think it would be a disservice to, leave portions out, in the vocabulary. And I also share, as far as concern that, yes, that's very broad. And, Farz, I'll I'll reach out about some ideas I have about mitigating that that that danger. Thank you.
[01:06:30] Suresh Krishnan: Paul?
[01:06:33] Speaker 1: I think to to what Tim and Robert said at the end, the we need to cover we know from from all of our interactions about the last one and a half years or so that we have people who have very different expectations with regards to both the expression of preferences that they want to make and in how far they would see to they would see a reason to honor these preferences. And they seem to be split along this line between autonomously fetched versus user contributed. And if we're not providing for the ability to express this difference, one side of these discussions will sort of need to ignore the larger category in order to come to that thing versus when we allow the expression of these two halves of the thing. Actually, the expression of preferences and the the the the following of the the the preferences can be much tighter scoped, and I think it's better. And if you if you express both as regards to no or yes, you're you're still covering the entire field.
[01:07:51] Mark Nottingham: Okay. Sebastian.
[01:07:55] Sebastian: I was just wondering if we have terminology for the two modes that we may want to separate, like the user submitted content or the situation where the model would go out and fetch content based on the prompt. So if if something like inference or RAG would be I think we kind of disregarded these terms, but I think it's relevant also because this will have influence on the attachment draft. Because if you, let's say, upload or if a user uploads a PDF file and asks in a prompt to do something with that PDF file, it's clear that the that the AI preferences need to be attached on the asset level. So in in in in a certain way, Nate's proposal would kind of be maybe helpful in that way that we do not need to distinguish these and say everything that happens after the model has been trained. However, if we want to separate these two modes, we should identify them with a proper term just to avoid confusion in the discussion.
[01:09:14] Mark Nottingham: That's an interesting proposal, Sebastian. I think, you know, if someone's willing to go off and and and make a proposal for the terminology, separate from the so we actually allow, you know, a differentiation of preference, it might help our discussions, in in having a clear idea of what that line is. Nate?
[01:09:41] Nate: Yeah. So I I wanna volunteer if Paul or anyone else wants to to reach out to me, and we can come up with possibly it sounds like I I like what you're saying, Paul, about having two different halves that kinda together make a whole, and I think that's that's a sensible version. Where I was originally thinking was just taking my definition and just on the second sentence where it says inference means all use inserting by autonomous systems or by, you know, end users and somehow just making sure that those two things are you know, cover the full field. But it sounds like maybe something like that is is a potential productive path forward.
[01:10:19] Mark Nottingham: Right. So
[01:10:29] Farzaneh Badiei: this is we've been discussing this for a year and a
[01:10:33] Kevin: half. We
[01:10:34] Farzaneh Badiei: have discussed the implications. We Paul, can you mute yourself? I can hear you on your keyboard. Thanks. And we have time and time again, people who work with end users and open source developers as well as public interest group have mentioned that this could, especially when you want to focus on the user and the their prompts, this could have an impact on the on the consumer side of things. So we need to be very careful and, you know, we need to go back to those arguments and see carefully what happened there and what the concerns were. It is very concerning for me that, like, I I see, like, the groups that we we discussed this. We said that the we discussed that it should not affect the consumer who's using the the AI. But now we are literally talking about the preferences applying to the consumer.
[01:11:50] Mark Nottingham: Nate, I'm assuming that's an old hand. Timid robot.
[01:11:57] Timid robot: So, again, I believe I I share many of the concerns that that Parz has, but I I the problem that I encountered in trying to address those concerns is that it's my understanding that this working group isn't invested in difficult to define concepts like public interests, like open web, that that those kind of, you know, political or social ideas are are outside the scope. And so my my interest is in ensuring that we are, you know, kinda clear about the limitations of the preference, like in section 3.2, and also that we give people the ability to to express preferences in a way that, from my perspective, you know, honors public interest, honors open web. And so I'll be, I'll be submitting a, a proposal hopefully in early August, about about parameters that would allow people to do that. Thank you.
[01:13:24] Mark Nottingham: Suresh. Yep. Any other thoughts? So, we've got about fifteen minutes left. As I said, I'm not sure we'll use the whole time. We have an interim meeting in a fairly short amount of time, just about a month from now. And I think as chairs, our primary interest is is making sure that we can do whatever we can between now and then to make that meeting really productive. And that includes the the two pull requests we had. If we can get those nailed down on the list between now and then, that would be good progress. If not, we'll discuss them there. Likewise, other parts of the text, we'll we'll take a look at. I think we'll do a a survey of the issues list, and we'll we'll communicate more in the mailing list about issues we're proposing to close because they've been overcome by events or combine them to make sure that we can focus on the parts of the specification that matter. Regarding this use inference, whatever you wanna call it issue, if people have proposals, either modifications to current ones or new ones, bring them to the list as much as you can before the meeting to give people time to consider them. Especially, I I found the idea about defining terminology, you know, so that we can talk about that line in a meaningful way really interesting because that might help clarify the discussion of whether we should have such a line and how we should allow people to express preferences for it. And we'll start putting an agenda together for the meeting in the next couple of weeks. So if you have ideas for the agenda, please come to us. Other than that, do we have anything else to discuss today?
[01:15:08] Suresh Krishnan: No. I just wanna make sure that people understand, we don't have an AAUs category in the document today. So, like, we continue to iterate on it until we put something in, if you put something in. And and far as if you have issues with three dot two, the right thing to do is go on the GitHub, comment on it. If you don't agree, what don't you agree with? So we can make forward progress on it because I think the group seems to be converging towards, like, some version of Sebastian and Martin's text in there. So if you have concerns with that, like, engage on the issue, that'll be great. Thank you.
[01:15:43] Mark Nottingham: Farz?
[01:15:46] Farzaneh Badiei: Yeah. I don't know how to say this so that it's clear. I have no issue with adding section 3.2, and I have also said that we will look into Sebastian's a paragraph that like, the replacement, which so but and I think and I also agreed on the mailing list that it should be added. What I do not agree with is that that is enough for public for public interest and other things that that our work doesn't doesn't hamper access to the Internet and AI services. So I don't and I think that, you know, we need to work on the definitions more, and we need to discuss the def definition. That's that's all I'm saying. I'm not I'm not saying that I'm not comfortable with section 3.2. I'm actually I was involved with that conversation. Thank you.
[01:16:47] Mark Nottingham: Okay. Thanks. Thanks, Farz. Tom?
[01:16:56] Tom: Hello. Thanks. Sorry. I should have been standing in the queue waiting probably. So this this machine readability draft thing, just wanted to bring up and flag for anyone who hasn't seen it. I put a thing in the mailing list announcing it. It's basically an attempt at defining what machine readability is because it's it seems to be being lent on quite a lot in lots of different policy documents. And for what it's worth, there's so the zero zero, the dash zero zero as it is right now is kind of troublesome. So we're working on a a dash o one. I say we, it's Hank sorry. Hank, Berkholz, and I, and a couple of other people are gonna refine it and make it a little bit more watertight. But if if anyone has any input on that, there's a link in the mailing list to the repo with issues and a wiki and so on. So
[01:17:56] Mark Nottingham: Thank you. And and just in in general, I think, we really encourage folks to collaborate. If if you can identify chunks of these issues or definitions or anything else, working with other people, especially working as it were across the aisle, really helps us have a better quality discussion in when when we do come together and meet and on the mailing list. So if if you have something you wanna work on, feel free to announce it at the mic here or on the mailing list. The more we can get people working outside of these meetings on on kicking the the work down the road, I think the better outcome we'll have. Anyone else?
[01:18:35] Suresh Krishnan: Okay. Yeah. I just wanted to say one thanks to Leila and all the people who worked on the 3.2 text for a lot of work. So I know a lot of background work went into it. So thank you very much for leading this work and working on it.
[01:18:49] Mark Nottingham: Yeah. Actually, I'd I'd I'd absolutely. I think that was a really great example of of people coming together and working on a proposal to to move the the work meaningfully forward. So, please, more of this shows shows that we as a working group are maturing and learning to work together, and that's great.
[01:19:05] Suresh Krishnan: Yeah. I'll close off with Mark's. It
[01:19:09] Mark Nottingham: is the IETF's smallest and craziest bar. Alright. Thank you all very much. We will hopefully see folks in London in not too long. And as I said, we'll talk about other meetings as well. Thanks. Thank you. That's the first time I've ever heard someone woo AI preferences.