[ai-control] Re: ai-control Digest, Vol 29, Issue 50

[Brandon Butler <[e-mail]>]

Hi all,

Agreed with Lila and Jo - option 2 works for me, as well. And I think we’ve seen several endorsements of that language from folks who had expressed reservations about 3.2 in the past, so it seems like a good compromise. 


Fingers crossed,
Brandon

> On Jul 31, 2026, at 1:08 PM, Jo Levy <jlevy=[e-mail]> wrote:
> 
> I prefer option 2. I prefer the reference to “an entity that receives usage preferences has a choice…” over “stakeholders need to decide” as it is not clear who is a stakeholder. Also, it’s not clear that this group is positioned to conclude that stakeholders “need” to decide, particularly if the stakeholder is not a recipient of the usage preference.
>  
> From: Lila Bailey <[e-mail]>
> Sent: Friday, July 31, 2026 9:34 AM
> To: [e-mail]
> Subject: [ai-control] Re: ai-control Digest, Vol 29, Issue 50
>  
> On Section 3.2, I could accept options 1 or 2. Of them, I think 2 is probably the strongest.
>  
> On Thu, Jul 30, 2026 at 2:52 AM <[e-mail] <mailto:[e-mail]>> wrote:
> Send ai-control mailing list submissions to
>         [e-mail] <mailto:[e-mail]>
> 
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
>         [e-mail] <mailto:[e-mail]>
> 
> You can reach the person managing the list at
>         [e-mail] <mailto:[e-mail]>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ai-control digest..."
> 
> Today's Topics:
> 
>    1. Re: Proposed language for Sec 3.2 ([e-mail] <mailto:[e-mail]>)
>    2. Re: Proposed language for Sec 3.2 ([e-mail] <mailto:[e-mail]>)
>    3. Re: Proposed language for Sec 3.2 (Laurent Le Meur)
>    4. Proposed "AI System Inference" and "AI User Input" categories
>       (Nate Hake)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 30 Jul 2026 01:12:00 -0700
> From: [e-mail] <mailto:[e-mail]>
> Subject: [ai-control] Re: Proposed language for Sec 3.2
> To: Timid Robot Zehta <[e-mail] <mailto:[e-mail]>>
> Cc: ai-control <[e-mail] <mailto:[e-mail]>>
> Message-ID: <[e-mail] <mailto:[e-mail]>>
> Content-Type: multipart/alternative;
>         boundary="Apple-Mail=_D7D02A1D-C39A-4326-9203-8EE3FB8B8561"
> 
> 
> > My preference is option 2. I do not object to option 3. I object to option 1 because it imports legal, institutional, and ethical considerations into a vocabulary specification.
> > 
> > Best,
> > Tyler
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 703 bytes
> Desc: not available
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 30 Jul 2026 01:12:00 -0700
> From: [e-mail] <mailto:[e-mail]>
> Subject: [ai-control] Re: Proposed language for Sec 3.2
> To: Timid Robot Zehta <[e-mail] <mailto:[e-mail]>>
> Cc: ai-control <[e-mail] <mailto:[e-mail]>>
> Message-ID: <[e-mail] <mailto:[e-mail]>>
> Content-Type: multipart/alternative;
>         boundary="Apple-Mail=_D7D02A1D-C39A-4326-9203-8EE3FB8B8561"
> 
> 
> > My preference is option 2. I do not object to option 3. I object to option 1 because it imports legal, institutional, and ethical considerations into a vocabulary specification.
> > 
> > Best,
> > Tyler
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 703 bytes
> Desc: not available
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 30 Jul 2026 11:35:28 +0200
> From: Laurent Le Meur <[e-mail] <mailto:[e-mail]>>
> Subject: [ai-control] Re: Proposed language for Sec 3.2
> To: Timid Robot Zehta <[e-mail] <mailto:[e-mail]>>
> Cc: ai-control <[e-mail] <mailto:[e-mail]>>
> Message-ID: <[e-mail] <mailto:[e-mail]>>
> Content-Type: multipart/alternative;
>         boundary="Apple-Mail=_397FA4CE-C9F9-4E8C-A710-702224CEA414"
> 
> > My preference is option 3, because it does not repeat information found in the first part, but rather concludes the section.
> 
> > I do not object to option 2, even if I find the wording a bit redundant. 
> 
> > I object to option 1 because it insists on non-technical considerations.
> > 
> > Best,
> > Laurent Le Meur
> 
> 
> > Le 29 juil. 2026 à 15:53, Timid Robot Zehta <[e-mail] <mailto:[e-mail]>> a écrit :
> > 
> > Following the Jul 24 Fri meeting, the currents status of Update §3.2 Applying Preferences and §4 Vocabulary Definition by TimidRobot · Pull Request #213 · ietf-wg-aipref/drafts <https://github.com/ietf-wg-aipref/drafts/pull/213> is:
> > 
> > Largely uncontested first part:
> > 
> > This specification enables the expression of a defined set of preferences that
> > can be communicated and interoperably understood. Readers of this
> > specification should understand that it does not:
> > 
> > - provide for enforcement of these preferences;
> > - address if, how, or when preferences should be followed or not-followed;
> > - address technical, legal, contractual, or other mechanisms that might create
> >   a stronger requirement to follow or not follow preferences;
> > - consider situations or purposes that might justify following or not-following
> >   expressed preferences.
> > 
> > 
> > with three proposals for the last part:
> > 
> > 1) original
> > 
> > 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.
> > 
> >  
> > 2) Sebastian's
> > 
> > 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.
> > 
> > 
> > 3) Martin's
> > 
> > An entity that receives usage preferences has a choice whether to follow those
> > preferences. Multiple factors could influence that decision, but the decision
> > itself is outside the scope of this document.
> > 
> > 
> > Please help narrow the three options down to one. If you give a preference, please also state whether you object to any of the others.
> > 
> > Thank you,
> > 
> > -Timid Robot
> 
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 5613 bytes
> Desc: not available
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 30 Jul 2026 16:51:57 +0700
> From: Nate Hake <[e-mail] <mailto:[e-mail]>>
> Subject: [ai-control] Proposed "AI System Inference" and "AI User
>         Input" categories
> To: [e-mail] <mailto:[e-mail]>
> Message-ID:
>         <CA++fB=[e-mail] <mailto:[e-mail]>>
> Content-Type: multipart/alternative;
>         boundary="000000000000919ef40657d10623"
> 
> Hi all,
> 
> After Vienna, I connected with Paul and we worked on draft language for a
> split approach to inference: one category for use of assets identified by
> AI systems, and a separate category for use of assets identified by users.
> 
> *I've just created Pull Request #216
> <https://github.com/ietf-wg-aipref/drafts/pull/216> to add those two new
> proposed use/inference categories for this group's consideration.*
> 
> For ease of reference and discussion on the mailing list, I've copied the
> proposed categories here:
> 
> *AI System Inference {#ai-system-inference}*
> Using an asset for inference by an AI model that is used to generate
> synthetic content in one or more modalities. Inference means all use beyond
> the modification of an AI model’s learned parameters. This category does
> not include the use of assets that a human end user has specifically
> identified (by providing either the asset itself or a location from which
> it can be retrieved).
> 
> 
> *AI User Input {#ai-user-input}*
> Using an asset that a human end user has specifically identified (by
> providing either the asset itself or a location from which it can be
> retrieved) for inference by an AI model that is used to generate synthetic
> content in one or more modalities. Inference means all use beyond the
> modification of an AI model’s learned parameters.
> 
> 
> Here are the advantages I see to this split approach:
> 
>    - This starts precisely where the AI-training definition (as proposed in
>    Kevin's PR 211) leaves off, using "the modification of an AI model’s
>    learned parameters" as a bright-line boundary
>    - The two proposed definitions work tightly together, such that there is
>    no undefined space left between them
>    - Thus, together with ai-train, this allows the expression of
>    preferences that cover the entire field
>    - This split approach also allows declaring parties to express, and
>    consuming parties to receive, different preferences for when assets are
>    used by autonomous systems vs when assets are identified by a human end
>    user
> 
> A few things to note that might warrant further discussion among the group:
> 
>    - The "specifically identified" and "location from which it can be
>    retrieved" language is intended to capture the situation where a user
>    provides a url instead of directly uploading content. I think this is fair
>    and proper to include in the user input category, although including it
>    does make the definitions a bit more verbose. Others may have different
>    views.
>    - These will both naturally need updating as we refine the training
>    category, so that they match. For example, I’ve left “synthetic” in there
>    since it’s still in PR 211, but there was discussion in Vienna on
>    potentially removing that term.
> 
> Of course, there are many other things that may warrant discussion too!
> 
> *I hope we can get some feedback and discussion on the mailing list so that
> we can hopefully make some progress on this as a group heading into
> London. *
> 
> Thank you,
> Nate
> 
> PS - Just as an fyi, Paul is on vacation for the next couple weeks. I'll
> try to keep this discussion advancing in the meantime.
> 
> 
> ***
> Nate Hake
> Founder
> TravelLemming.com <https://travellemming.com/>
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 5143 bytes
> Desc: not available
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> ai-control mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
> ------------------------------
> 
> End of ai-control Digest, Vol 29, Issue 50
> ******************************************
> -- 
> ai-control mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]