On 1/28/25 10:19 AM, Murray S. Kucherawy wrote:
On Tue, Jan 28, 2025 at 10:08 AM Michael Thomas <m...@mtcc.com> wrote:
One of the earlier drafts of the charter was very, very open ended
about
the scope of work which concerned me. This version seems to be more
limited, but it's not explicit that the objectives are the actual
scope
of the work. Are they? If not, what is the actual scope? How do
chairs
decide?
So you're looking for a "No other work is considered to be within this
charter" statement? If not, I'm not clear what you're asking for and
request some text you'd like to see added or changed.
I'm asking if that was actually the intention.
But in your objectives if that was the intention, you could make it
explicit to say that "The scope of the working group's work will address
the following objectives..." or something like that, so the chairs can
refer back to the charter to not take on new work.
That is, suppose somebody wrote a draft to upgrade cipher suites. In
scope or not?
I will also note that the "back scatter" problem is mentioned, but is
not in the objectives. That suits me if the objectives are the scope,
but it makes it an orphan.
I think the third objective is the intended solution to the
backscatter problem, and one of the proponents should feel free to
either correct me or confirm.
That wasn't obvious to me, you might add some text that links the two.
And "annotations in transit"... annotations of what? Also "intended"?
What might be considered "unintended"?
Also about mutations: you should probably be more precise that it's
mutations to the signed canonical text of a particular signature. That
is, just adding a received: header doesn't need to be considered.
One last thing: the charter seems like it's dancing around with whether
to just upgrade DKIM or do something new. DKIM explicitly allows tag
upgrades by telling evaluators they MUST ignore unknown tags. I think we
should make explicit that adding a new tag is not a reason to create
something new. That is, adding a new tag to a DKIM signature block is
not "disturbing" the existing ecosystem.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
