On Sat, Dec 31, 2022 at 4:18 PM Michael Thomas <[email protected]> wrote:
> > On 12/31/22 2:37 PM, Murray S. Kucherawy wrote: > > On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas <[email protected]> wrote: > >> >> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote: >> >> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas <[email protected]> wrote: >> >>> >>> >>> Done, and thanks for that text. >>> >>> One nit, Barry's text should be above the proposals not below. It makes >>> it look like those are the only proposals on the table which I'm nearly >>> certain is not your intent. >>> >> One other thing though, should there be some bounds on what appears to be >>> the possibility of writing a BCP like document? I mean, I can think of some >>> things that could help mitigate this but they are pretty wonky and >>> definitely untested. Do we actually have that operational experience to >>> recommend anything? >>> >> >> The charter as-is is now up for IESG Evaluation and one AD has already >> commented on it, so I'm going to hold any edits until after the next >> telechat (on January 5th) so as not to give them a moving target. After >> that I'll apply this and any other feedback. >> >> That's fine, but we can talk about it in the mean time, right? I'm not >> suggesting a specific change on the BCP part because I'm not exactly sure >> what we should do. I know that it seems "obvious" but it also seems to me >> that we could get out in the weeds really easy and recommend stuff that we >> probably shouldn't. That's what I'm struggling with respect to "bounds". >> I'm not sure that we have the operational knowledge -- or more likely >> operational knowledge that can be shared -- to recommend something? >> > I expect that one of two things will happen: (1) We will attract a > sufficiently broad set of contributors that whatever consensus they come up > with will be defensible because it collectively has the operational > knowledge and expertise to make appropriate BCP-style recommendations to > the industry, or (2) we will not, and we'll know it, and thus we'll know we > can't produce defensible advice suitable for publication. > > Maybe we can put the same constraint on this as we do for protocol work > going forward as in having a step which determines whether there is a 1) > plausible route forward or not and 2) whether it's really within the scope > of what IETF can recommend. Sort of the same A/B switch. > > Mike > I'm worried about duplicating work unnecessarily as the M3AAWG has an email authentication BCP. If the WG to-be indeed does want to generate the BCP, perhaps the M3AAWG document can be the basis for an IETF document assuming M3AAWG is okay with that, or the WG can partner with M3AAWG to produce a common document. I think both are possible as there's a fair amount of people overlapping between the IETF and M3AAWG, and I know that M3AAWG organizationally wants to help here. That said, I think a BCP around the existing email authentication standards can only provide workarounds that can be bypassed by spammers i.e. new standards are needed to properly mitigate the current risk. -Wei > > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
