Re: [arch-d] Domain-based Message Authentication, Reporting & Conformance (dmarc) WG Virtual Meeting: 2020-06-11
S Moonesamy <sm+ietf@elandsys.com> Wed, 13 May 2020 16:28 UTC
Return-Path: <sm@elandsys.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3AE3A0B78; Wed, 13 May 2020 09:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiUdV4x1kP7x; Wed, 13 May 2020 09:28:49 -0700 (PDT)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6C3A0B3C; Wed, 13 May 2020 09:28:49 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.121.210]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 04DGSXHU027066 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2020 09:28:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1589387327; x=1589473727; i=@elandsys.com; bh=ONZV2xFpv/Ueh2aIXMt2rvWXBVtWCdKQz9fhoso9Oeg=; h=Date:To:From:Subject:In-Reply-To:References; b=WBGsSW9t1d8Qj8IvpGFGX3iF6LSGBwoO6ixcSlMc4mlHUu8a8OgzR7izazC2AKOLI yfV0gNRHrslceU2m/S3D7494CxIKOBAOWkuF1dMew0vafCGeIDJOHcDk1XozAALRTm h1ia7/yXyZF8zAi8ch+L9/FHS8IPbgx/hn98tcl8=
Message-Id: <6.2.5.6.2.20200513081326.0ababe28@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 13 May 2020 09:25:42 -0700
To: Barry Leiba <barryleiba@computer.org>, iab@iab.org, architecture-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <CALaySJKs9oLXBN_UVq=Mn5ZefvrSgPyrV1J=1NMA0=YVDRnJVA@mail.g mail.com>
References: <158920530782.23655.6622928751672901506@ietfa.amsl.com> <6.2.5.6.2.20200512152625.124c1588@elandnews.com> <d798d383-9bab-50f8-b6ee-dabb9cc37c2a@cs.tcd.ie> <6.2.5.6.2.20200512162358.0b239160@elandnews.com> <4548adba-834c-bfdd-36af-66b367408df8@cs.tcd.ie> <6.2.5.6.2.20200512191150.0bafa9a0@elandnews.com> <9161f68e-f51b-f97b-fc2b-372d24404209@cs.tcd.ie> <CAL0qLwZQxM+eDeZ+zFw3Gny7sy=jXi-1aUvE1B2RuO=M5CP_Sw@mail.gmail.com> <6.2.5.6.2.20200512232644.0d9328c8@elandnews.com> <CALaySJKs9oLXBN_UVq=Mn5ZefvrSgPyrV1J=1NMA0=YVDRnJVA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/0mnwX0eJZ1idp7Ts75fEmBXvH5E>
Subject: Re: [arch-d] Domain-based Message Authentication, Reporting & Conformance (dmarc) WG Virtual Meeting: 2020-06-11
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 16:28:52 -0000
Dear Barry, IAB, At 07:07 AM 13-05-2020, Barry Leiba wrote: >(Removing IAB from the distribution.) Thanks for teh quick reply. I am copying my reply to the IAB. >Adding to that: >Not all inter-organization activity happens with liaison statements, >and it's best when it doesn't happen that way: the most effective way >for organizations to work together is through cross-participation. In >the case of M3AAWG, there are quite a few IETF participants who are >also active M3AAWG participants, so there's a good flow of work and >information back and forth, and that's healthy for both IETF and >M3AAWG. My role as the IETF liaison to M3AAWG has included helping >M3AAWG participants come over to the IETF to participate, to make sure >M3AAWG is aware of work in the IETF that's relevant to them, and to >make sure that the IETF -- the IESG, the IAB, and the appropriate >working groups -- is aware of things going on in M3AAWG. That has >worked well, and some work in the former SPFBIS working group and the >current DMARC and UTA working groups has originated in M3AAWG and been >brought over. I don't recall seeing any information flowing towards the IETF. I did not bother much about that until I read a recent comment, which is unrelated to DMARC. The liaison relationship isn't for the benefit of the IAB or IESG only as the liaisons are described as representing the IETF (please see my exchange with Stephen about that). >This is also not the first time that IETF working groups have had >joint meetings with other organizations -- more accurately, IETF >sessions where other organizations' members are explicitly invited to >join: these meetings are always held under IETF Note Well and are open >to all participants. My experience with such meetings is that the >IETF working groups have benefited from targeting participation of the >other organizations' members. > >I'm not sure, SM, what your apparent skepticism or concern is about >this. Perhaps you can be clearer about why you're pushing on it. My concern is that there is very little information about what the liaisons representing the IETF are doing. I don't recall anyone asking questions about that unless the practice is to keep those discussions behind closed doors. I requested a summary of the discussions which led to the proposed virtual interim. The reply (please see above) mentions that: 1. It is not the first time that the IETF has a joint meeting. 2. The IETF benefits from targeting participation from other organizations. None of that addresses the question which I asked. Are liaisons relationship for outreach (2)? I don't see anything in the relevant documents which mention that as the primary purpose. For example, there is the following: "Some IETF liaison managers send reports to the IAB for publication to the wider community. This practice was more common in the past, and previous reports are archived here". For what it is worth, the reports are not available on the IAB web site as the link is a 404. Is that statement for marketing purposes? There is also: "In setting up the relationship, the IAB expects that there will be a mutual exchange of views and discussion of the best approach for undertaking new standardization work items." Does M3AAWG has any concern about the standardization work being done in the IETF DMARC Working Group? For what it is worth, I was in SPFBIS. I was not informed about any M3AAWG communication. When was the liaison relationship with M3AAWG set up? Was there any communication "representing the IETF" since then? >No; it's an RFC, published in the Independent Stream, but not an IETF >publication. But (1) few people really understand that distinction, >and (2) what you're pointing to is a press release from a private >company for marketing purposes, and its "spin" shouldn't surprise >anyone. Again, what do you think the IETF's concern here is? I gather that nobody will raise any objection if someone else was to list himself/herself as IETF and add some marketing comment saying that the IETF published a "NewIP" specification. Regards, S. Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Stephen Farrell
- Re: [arch-d] Domain-based Message Authentication,… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Stephen Farrell
- Re: [arch-d] Domain-based Message Authentication,… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Stephen Farrell
- Re: [arch-d] Domain-based Message Authentication,… Murray S. Kucherawy
- Re: [arch-d] Domain-based Message Authentication,… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Murray S. Kucherawy
- Re: [arch-d] Domain-based Message Authentication,… Barry Leiba
- Re: [arch-d] Domain-based Message Authentication,… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Barry Leiba
- Re: [arch-d] Domain-based Message Authentication,… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Barry Leiba
- [arch-d] Liaison reports (was: Domain-based Messa… S Moonesamy
- Re: [arch-d] Domain-based Message Authentication,… Murray S. Kucherawy
- Re: [arch-d] Liaison reports Wes Hardaker
- Re: [arch-d] Liaison reports S Moonesamy
- Re: [arch-d] Liaison reports Guntur Wiseno Putra
- Re: [arch-d] Liaison reports Guntur Wiseno Putra
- Re: [arch-d] Liaison reports S Moonesamy
- Re: [arch-d] Liaison reports (was: Domain-based M… Mirja Kuehlewind
- Re: [arch-d] Liaison reports (was: Domain-based M… S Moonesamy
- Re: [arch-d] Liaison reports (was: Domain-based M… Bob Hinden
- Re: [arch-d] Liaison reports (was: Domain-based M… Mirja Kuehlewind
- Re: [arch-d] Liaison reports Alexandre Petrescu
- Re: [arch-d] Liaison reports Wes Hardaker
- Re: [arch-d] Liaison reports S Moonesamy
- Re: [arch-d] Liaison reports Wes Hardaker
- Re: [arch-d] Liaison reports S Moonesamy
- Re: [arch-d] Liaison reports (was: Domain-based M… Spencer Dawkins at IETF
- Re: [arch-d] Liaison reports Spencer Dawkins at IETF
- Re: [arch-d] Liaison reports Mirja Kuehlewind