The IESG will be reviewing the BoF I filed, which links to the proposed
charter, tomorrow.  Having received no adverse feedback, I'm going to
submit that last charter text (as amended below) to the datatracker shortly.

On Thu, Jan 16, 2025 at 3:08 AM Richard Clayton <rich...@highwayman.com>
wrote:

> I expect you mean effecting (but rewording would be better)
>

Fixed.


> >    re-injection into the ecosystem.  There are complexities with this
> >    handling model, such as evaluation, filtering, intentional
> >    mutation, and even malicious activities.
>
> [...]
>
> in your list of problems you have ignored the issue that ESPs have in
> handling errors (they send messages on behalf of a client but reports
> about delivery failures may pass them by and go back to the client).
> They currently mangle various indicators of who generated a message to
> address this, but that damages the notion you call authentication.
>

Added:

* Service providers that generate mail on behalf of an entity have no
visibility into any resulting errors, as they are sent to the entity and
not the provider.


> >    The working group will observe the success of current technologies,
> >    primarily DKIM, reusing its techniques where applicable, to develop
> >    a new technology suite that seeks to address these concerns.  Early
> >    experience from the deployment of ARC [RFC 8617] will also be
> >    considered.
>
> I note that experience is mainly negative (viz it has not proved to be
> an effective fix) but yes, we should consider that.
>

Has any been published anywhere?  If not, I think we have to say something
neutral like this.


> >    Proposed Milestones
> >
> >    [dates to be negotiated; focus on the sequence for now]
> >
> >    WG Formation: Jan 2025
> >    Overview document: Feb 2025
> >    Mechanism document draft(s): Mar 2025
> >    Experiments and drafts: Apr 2025 - Nov 2025
> >    Implementation guide: Nov 2025
> >    Publish documents as a group: Dec 2025
>
> I note that the overview document will require regular revision
> throughout -- not so much as to the nature of the problems being
> addressed, but how the (evolving in the light of experience) protocol
> addresses them.  Also, it may be a matter of judgment what goes into the
> overview and what goes into the implementation guide.


> Of course all the documents may change as we go along but this one (with
> it's early milestone) seems more likely to change than the others and
> perhaps the text here should call that out.
>

The dates can flex.  The charter just needs to call out the intent and
roughly a sequence or anything else pertinent to how the WG will operate.

The overview document also doesn't need to be future-proof; it's great if
it jives 100% with the specification documents when they later appear, but
I don't think it's fatal if they end up being in slight disagreement.

For that matter, it doesn't actually have to get published if in the end
it's not found to have any archival value.

-MSK
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Reply via email to