[ai-control] Re: Proposed language for Sec 3.2

[Farzaneh Badiei <[e-mail]>]

we had a conversation about this paragraph last week and I leave it to the
chairs to let us know how we can move forward and I just saw that Timid R
posted it on this thread.


Since the issue of IETF is technical repeatedly is being raised to make
changes or stop changes from happening I wanted to bring my point of view
about that.
I have known about the IETF's work since at least 2011, and their emphasis
on the work being "technical" was very important and appreciated. I even
co-authored two papers why the IETF should be kept technical and how policy
issues should be sorted out elsewhere.

But in my opinion this group  has been struggling with going into policy
territories since the beginning. If we wanted to keep this group purely
technical we would have implemented opt-out mechanisms for "technical"
reasons. For interoperability, security, confidentiality. I am opting out
because this link has this technical issue or because of server-load and if
you crawl it can affect people's access. Or you are heavily crawling and my
network being overwhelmed. Interoperability issues. Of course the signaling
can be used for other non-technical motives but this group wouldnt have
cared about that.
But now we are signaling because "I dislike that this crawler trains on my
content;" or "that company trains on my content I want to opt out". that is
not a technical reason. "Or that traffic has been diverted from my website
and my revenue is being affected so I need a mechanism to block and then
charge these companies or everyone I want to". or that "I need a mechanism
to prove in court that I told them not to train and they did train". If the
work of this group is going to be technically enforced in another group at
the IETF as well, then in a way we are providing the market with all the
incentives and tools to privately adjudicate copyright issues.

At some point we even had certain categories like TDM or automated
processing terms straight out of laws and regulations!! All in all I think
we need to recognize and acknowledge that this group is a little bit
special and not be in denial. I am not saying IETF is not the place to do
this ... but I think claiming “IETF is technical” and treating these
signals as just signals without considering what has changed and how
different this group is doesn’t lend itself to a good conversation that can
solve the problems we are raising! In other words, let's have a substantive
conversation and not just argue that IETF is technical when some of us
argue that some of the definitions and categories can impact people's
access to online services and content and sometimes some of these
signaling  can possibly lead to copyright overreach.









On Fri, Jul 24, 2026 at 7:34 AM Sarah McK <[e-mail]> wrote:

> +1 to this: " lacks the ability to consult with the wide range of
> stakeholders" -- the IETF is a very valuable organization precisely because
> they are one of very few valid global technical standards setting bodies
> but the fact that they require stakeholders to discover their working
> groups and send emissaries to participate is probably the biggest weakness,
> there is no funding for outreach/participation to ensure affected parties
> have adequate representation.  That said, I am not sure there is a better
> place for this work...
>
> On Thu, Jul 23, 2026 at 9:28 AM Chris Needham <chris.needham=
> [e-mail]> wrote:
>
>> I very much agree with Andrew. Not only does IETF lack the competence to
>> address policy matters, its consensus based approach is the wrong structure
>> to resolving what are a set of competing interests. It also lacks the
>> ability to consult with the wide range of stakeholders needed. The small
>> self selected set of individuals in this working group isn't that.
>>
>> Chris
>>
>>
>> ------------------------------
>> *From:* Andrew Campling <[e-mail]>
>> *Sent:* 22 July 2026 10:47
>> *To:* Deen, Glenn (Comcast Cable) <Glenn.Deen=[e-mail]>;
>> Victoria Noble <[e-mail]>; Brandon Butler <[e-mail]>;
>> Sebastian Posth <[e-mail]>; ai-control <[e-mail]>
>> *Cc:* Leonard Rosenthol <[e-mail]>; Laurent Le Meur <
>> [e-mail]>; Deen, Glenn (Comcast Cable) <
>> [e-mail]>
>> *Subject:* [ai-control] Re: Proposed language for Sec 3.2
>>
>>
>> *External: * Think before clicking
>>
>> +1 to Glenn’s point below.
>>
>>
>>
>> In my view, the I*E*TF lacks competence to address such matters of
>> policy and should leave the topic to other fora.  If the community is
>> determined to proceed with Section 3.2, it really ought to broaden the text
>> to cover all the related policy, legal regimes etc.  This would be unwise
>> and reaching consensus with any such content is improbable.
>>
>>
>>
>>
>>
>> Andrew
>>
>>
>>
>> *From:* Deen, Glenn (Comcast Cable) <Glenn.Deen=
>> [e-mail]>
>> *Sent:* 22 July 2026 06:44
>> *To:* Victoria Noble <[e-mail]>; Brandon Butler <
>> [e-mail]>; Sebastian Posth <[e-mail]>;
>> ai-control <[e-mail]>
>> *Cc:* Leonard Rosenthol <[e-mail]>; Laurent Le Meur <
>> [e-mail]>; Deen, Glenn (Comcast Cable) <
>> [e-mail]>
>> *Subject:* [ai-control] Re: Proposed language for Sec 3.2
>>
>>
>>
>> I agree that the discussion should focus on the meaning of the
>> vocabulary. However, once we begin introducing language about when
>> expressed preferences should be followed and when they may be disregarded,
>> we have moved beyond questions of meaning and into questions of enforcement
>> and policy.
>>
>>
>>
>> Determining when expressed preferences can be ignored falls outside the
>> scope of this working group’s mission. A vocabulary definition document
>> defines terms and concepts; it does not define the circumstances under
>> which statements made using that vocabulary must be followed, enforced, or
>> set aside.
>>
>> For example, Webster’s Dictionary defines words but does not address when
>> ideas expressed in English should be heeded or ignored. The HTML
>> specification defines the elements of a web page but does not establish
>> access-control policies for websites built with HTML. Likewise, a
>> description of a car’s components—its wheels, tires, and engine—does not
>> include the legal requirements governing who may drive it.
>>
>> In the same way, a vocabulary definition document is not the appropriate
>> place to establish policy regarding the treatment of preferences expressed
>> through that vocabulary.
>>
>> This topic is outside the scope of this group’s charter. Just as we have
>> deliberately avoided debating how copyright, database rights, and other
>> legal regimes apply to AI, we should avoid debating when expressed
>> preferences may be overridden.
>>
>> Including language that specifies circumstances under which expressed
>> preferences can be bypassed would give one policy issue preferential
>> treatment while excluding discussion of other equally relevant policy
>> considerations raised by stakeholders. Early in the chartering process, the
>> group agreed to set aside questions relating to copyright and other legal
>> rights regimes. The question of when preferences may be disregarded is
>> closely intertwined with those same policy and legal issues.
>>
>> I very much appreciate the importance of such issues and do not want to
>> imply they are not important.   They are very much central to the broader
>> discussion of AI’s use of content, but inserting a very specific policy
>> into the vocabulary definition work now, complicates the small step forward
>> we are working on by opening the door to those other commingled policy
>> topics.
>>
>> If we choose to include such language now, we risk reopening the broader
>> set of policy debates that the group intentionally decided were outside its
>> scope. That would undermine the boundary the charter established and draw
>> the working group into precisely the “can of worms” it agreed not to
>> address.
>>
>>
>>
>> regards
>>
>> Glenn
>>
>>
>>
>>
>>
>>
>>
>> *From: *Victoria Noble <[e-mail]>
>> *Date: *Tuesday, July 21, 2026 at 11:52 PM
>> *To: *Brandon Butler <[e-mail]>; Sebastian Posth <
>> [e-mail]>
>> *Cc: *ai-control <[e-mail]>; Leonard Rosenthol <
>> [e-mail]>; Laurent Le Meur <[e-mail]>; Deen,
>> Glenn (Comcast Cable) <[e-mail]>
>> *Subject: *[EXTERNAL] Re: [ai-control] Re: Proposed language for Sec 3.2
>>
>> Strongly agree with Brandon. I can’t see a path towards consensus on a
>> document that doesn’t include section 3.2, and in particular, language that
>> recognizes that the public interest may take precedence over preferences
>> under certain circumstances. Protecting these public interest uses is
>> extremely important to me and others from the public interest community.
>>
>>
>>
>> Victoria (Tori) Noble
>>
>> *Electronic Frontier Foundation*
>>
>> *My working hours may not match yours. Please respond at your
>> convenience.*
>>
>> *From: *Brandon Butler <[e-mail]>
>> *Date: *Tuesday, July 21, 2026 at 2:38 PM
>> *To: *Sebastian Posth <[e-mail]>
>> *Cc: *ai-control <[e-mail]>; Leonard Rosenthol <
>> lrosenth=[e-mail]>; Laurent Le Meur <
>> [e-mail]>; Deen, Glenn (Comcast Cable) <
>> Glenn.Deen=[e-mail]>
>> *Subject: *[ai-control] Re: Proposed language for Sec 3.2
>>
>> Agreed. This discussion is about the meaning of the vocabulary, not how
>> it is attached. Also, as someone  especially invested in this issue, I’m
>> not sure folks like me are going to be able to join a consensus around a
>> document that omits it, in hopes that the next phase might correct the
>> omission.
>>
>>
>>
>> On Tue, Jul 21, 2026 at 4:42 PM Sebastian Posth <[e-mail]>
>> wrote:
>>
>> I don't quite understand why a general discussion of the vocabulary's
>> applicability (however limited or extended that would be defined) would be
>> better suited to the context of the attachment draft, which focuses
>> specifically on describing methods for binding the vocabulary's expressions
>> to content. – I rather believe that section 3.2 of the vocabulary draft is
>> the right place for this statement. Moreover I believe that this discussion
>> should not be postponed.
>>
>> Kind regards,
>>
>>
>> Sebastian
>>
>>
>>
>>
>>
>> On Tue, 21 Jul 2026 at 20:23, Laurent Le Meur <[e-mail]>
>> wrote:
>>
>> I like Leonard's proposal.
>>
>>
>>
>> The "vocabulary" specification is a dictionary of terms that will be used
>> in different contexts.
>>
>> Most of us would like this specification to be completed asap by
>> important missing terms (*ai-grounding* and maybe ai-input).
>>
>>
>>
>> It makes sense to move the current discussion to the "attachment"
>> specification, which provides a specific context (robots.txt, web crawlers
>> ...) for the use of the vocabulary.
>>
>>
>>
>> Best regards
>>
>> Laurent Le Meur
>>
>> EDRLab
>>
>>
>>
>> Le 20 juil. 2026 à 17:14, Leonard Rosenthol <lrosenth=
>> [e-mail]> a écrit :
>>
>>
>>
>> The more I listen to this conversation, the more I wonder if this entire
>> thread is happening at the wrong time (i.e., premature).  More
>> specifically, it seems more closely tied to the attachment work, rather
>> than the vocabulary work.
>>
>>
>>
>> Vocabulary is just that - vocabulary.  It shouldn’t, IMO, say anything
>> about HOW or WHERE it will be used.   Think Dictionary - nothing in a
>> dictionary instructs the use (or lack thereof) of any given words/terms.
>>
>>
>>
>> Attachment is where we get into more “nitty gritty” about the actual
>> usage of the terms from the Vocab.  I could very well see us talking about
>> this sort of stuff there as that is about how the consumers will find the
>> data and what to do with it.
>>
>>
>>
>> Discuss 😉.
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *Deen, Glenn (Comcast Cable) <Glenn.Deen=
>> [e-mail]>
>> *Date: *Monday, July 20, 2026 at 11:02 AM
>> *To: *ai-control <[e-mail]>
>> *Subject: *[ai-control] Re: Proposed language for Sec 3.2
>>
>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>
>>
>>
>> @EKR - Thanks for asking about if this is argument over wording or
>> something deeper.   - From my perspective it’s something deeper, but is
>> also tied into the wording being proposed.
>>
>>
>>
>> I agree and recognize that this is not a specification that includes any
>> sort of technical enforcement mechanism. We have nothing about enforcement
>> mechanisms in the charter, and to be clear, I am not suggesting that the
>> specification should define one.
>>
>>
>>
>> However, the absence of an enforcement mechanism is not the same thing as
>> declaring that publishers' expressed preferences are merely optional and
>> may be ignored whenever doing so is convenient for a consumer of the
>> published content.
>>
>>
>>
>> That distinction is a large part of why I have concerns with the proposed
>> language in Section 3.2. I will say that Chris's suggestion comes closer
>> than any of the other proposals to addressing some of those concerns.
>>
>>
>>
>> My biggest difficulty is reconciling two seemingly contradictory goals.
>> On the one hand, we are creating a vocabulary specifically to allow content
>> publishers to express their preferences. On the other hand, we are
>> considering language that appears to encourage consumers of those
>> preferences to disregard them when it suits their interests.
>>
>>
>>
>> If the purpose of this work is to provide a mechanism for publishers to
>> communicate their preferences, then those preferences must carry some
>> meaningful weight. Otherwise, it is unclear what value the vocabulary
>> provides or the publishing of preferences provides.
>>
>>
>>
>> Put another way: if a consumer intends to ignore AI Preferences
>> regardless of their content, why read them at all? Conversely, if a
>> consumer chooses to read the preferences, what is the justification for
>> disregarding them? The specification may not enforce compliance, but it
>> should not undermine the very purpose of expressing preferences in the
>> first place.
>>
>>
>>
>> I’m here at IETF126 if anyone wants to discuss in person.
>>
>>
>>
>> regards
>>
>> Glenn
>>
>>
>>
>> *From: *Eric Rescorla <[e-mail]>
>> *Date: *Friday, July 17, 2026 at 6:52 PM
>> *To: *Brandon Butler <[e-mail]>
>> *Cc: *Timid Robot Zehta <[e-mail]>; Jo Levy <jlevy=
>> [e-mail]>; Deen, Glenn (Comcast Cable) <Glenn.Deen=
>> [e-mail]>; [e-mail] <[e-mail]>;
>> Deen, Glenn (Comcast Cable) <[e-mail]>; Chris Needham <
>> [e-mail]>
>> *Subject: *Re: [ai-control] Re: [EXTERNAL] Proposed language for Sec 3.2
>>
>> Yes, this seems good.
>>
>>
>>
>> Glenn, Chris, I'm trying to figure out whether this is an argument over
>> wording
>>
>> or something deeper. My understanding of this spec has always been that
>>
>> this is merely an expression of preference with no intrinsic normative
>>
>> force, even beyond that of ordinary IETF specs.
>>
>>
>>
>> What I mean by that is that it's common for specs to say "if you
>> implement this
>>
>> protocol you MUST do X" but that you're free to not implement the protocol
>>
>> at all, in which case you don't need to do X. So, for instance, you can't
>>
>> be a conformant implementation of TLS 1.3 unless you implement P-256.
>>
>>
>>
>> However, I had always understood the agreement to be that you could be a
>>
>> conformant implementation of AIPREF that decided to ignore some set of
>>
>> preferences for <reasons>, and that the specification would not restrict
>> what
>>
>> those reasons were.
>>
>>
>>
>> Do you disagree with this?
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 17, 2026 at 9:41 AM Brandon Butler <[e-mail]>
>> wrote:
>>
>> Exactly - indeed, it may be worth another slight tweak to make that
>> clear. Perhaps the wording of the last paragraph could be:
>>
>>
>>
>> Because of this, stakeholders need to decide when and how to follow or
>>
>> not-follow preferences in the context of other legal, institutional, or
>>
>> ethical*, or other interests and* commitments.
>>
>>
>>
>>
>>
>> Take care,
>>
>> Brandon
>>
>>
>>
>> On Jul 17, 2026 at 12:28:21 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>
>>
>> On Fri, Jul 17, 2026 at 9:23 AM Brandon Butler <[e-mail]>
>> wrote:
>>
>> Agreed. In the absence of legal or regulatory requirements to follow
>> preferences, users are free under this standard to choose not to follow
>> preferences based on ethical or institutional commitments.
>>
>>
>>
>> Or really, for any reason whatsoever.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> --
>> ai-control mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>> --
>> ai-control mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> --
>> ai-control mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> --
>> ai-control mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> --
> ai-control mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>