Bron/Murray/et al
Forgive if this charter stuff of mine is redundant. I don't think it is
and I don't claim to be an expert in mail.
tim
-----
## Objectives
This working group will take a holistic approach to the underlying problems
of attribution, error signalling, and trust relationships between the
entities involved in handling an email - from its inception to arrival at
its final destination. The working group will use the mechanisms of DKIM as
a basis, extending it to solve the problems that have been identified in
real-world usage.
It will be necessary for any new mechanism to work in parallel with the
existing attribution mechanisms, and have a clean upgrade path.
Q: Should there be some wording/text on interoperating forward/backward?
Also, should there be some text on working with other mail groups in and
out of the IETF?
The working group will coordinate closely with any current or new
email-related working groups (DMARC, extra, sml, etc? )
## Deliverables
This working group will produce the following document(s):
* A design overview describing the problem area and proposed mechanism
I think this could/should be broken out as:
* A design overview describing the problem area requirements (informational
RFC)
* A specification describing the proposed mechanism, which includes
operational analysis (standards track)
(While Bron has some great stuff proposed, it may make sense to write the
proposed mechanism separately. But always happy to be wrong. )
* A best practices guide for implementation during the changeover
period, in which interoperability with existing standards needs to be
maintained.
* A document providing implementation guidance for operators working
through the changeover.
(I do not say best practices because the IETF has this thing on Best
Practice documents)
## Milestones
* Design Overview
* Proposed Mechanism
* some period of time for interop testing
* profit
On Wed, Nov 20, 2024 at 5:47 PM Tim Wicinski <[email protected]> wrote:
> Jim/Murray,
>
> Thanks for reminding some of us of the link. Charter writing can be a bit
> specialized but the IESG has tried to simplify the process for new working
> groups.
> I do have some thoughts on text - mostly editorial.
>
> - should have section headers for "Background", "Objectives",
> "Deliverables", and "Milestones".
> - if we have an idea of the order of the documents, and the document types
> (standards, informational, bcp) we should throw it in there for the IESG.
>
> As a very relevant example we recently chartered a new working group to
> change the signaling mechanism between parent and child DNS zones.
> Take a look at the charter for DELEG:
> https://datatracker.ietf.org/wg/deleg/about/
>
> It does line up organizationally with the BFNEAS charter.
>
> (I may have found it useful to leave an obvious issue with the charter
> text wording in place to catch random IESG members.)
>
>
> tim
>
>
> On Wed, Nov 20, 2024 at 5:04 PM Jim Fenton <[email protected]> wrote:
>
>> On 20 Nov 2024, at 10:02, Murray S. Kucherawy wrote:
>>
>> > A reminder:
>> >
>> > Please avoid engaging in engineering discussions for the moment. We're
>> > discussing the proposed new charter and whether it's appropriate for a
>> > rechartering of DKIM to develop DKIM2.
>>
>> Yes, let’s do that. I keep having to search through my email for the
>> draft charter, so I’ll repeat the URL:
>> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>>
>> I’m not a very good charter creator. It’s a very specialized skill. It
>> doesn’t seem like the tone of this draft matches other charters I have
>> read, but I’m not sure how to correct that.
>>
>> My main comment is that it lists five documents as deliverables, but
>> makes it sound like they’re all independent. At some point there needs to
>> be a standards-track specification for DKIM2 created, and it will have
>> normative references to the other documents, like the error and bounce
>> handling, reverse changes algebra, and replay protection. Are all of these
>> considered essential for DKIM2?
>>
>> It would also be good to note somewhere that, unlike DKIM, references to
>> the message envelope are in-scope.
>>
>> -Jim
>>
>> _______________________________________________
>> Ietf-dkim mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
>
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
