IETF Logo Mail Archive

Re: [Sframe] Adoption call for draft-omara-sframe-01

Youenn Fablet <youenn@apple.com> Fri, 15 October 2021 17:05 UTC

Return-Path: <youenn@apple.com>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2383A08C5 for <sframe@ietfa.amsl.com>; Fri, 15 Oct 2021 10:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 X4Z4BlHQXBIX for <sframe@ietfa.amsl.com>; Fri, 15 Oct 2021 10:05:48 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDFE3A08D3 for <sframe@ietf.org>; Fri, 15 Oct 2021 10:05:48 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19FGqf5G012798 for <sframe@ietf.org>; Fri, 15 Oct 2021 10:05:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=SsnHPZvepQdbg4J+gQUePX1AjDvq/UUn5Uq2tmOk4VU=; b=bzwWSnl463zWwz0BchFtsRlt2E9/1DUwnAEbPhb2UST2NdVy45mJfAW7j2D9bOuGCguN b8W+ZEjwIVAHSQswrNjTA203bphaNkINXeqcOD5fcsTC8ZEkriXlLsNINBv79Z7wtxkO 7u7mgTSIEV2ZJLCcIDoiUAoDUWlRNvkQOrC2DzcP5vpYlNvCzLveMl7Z3Tuagp6K1H87 9b7xlnfWfJc7Ic+9qZw0qvT0GtdewGKtaU7UTEwbNvmC3gyoVmySZkpK/FhxGCcB6RdZ ayqhsTbL620iWqtEMirzdRDyqOxzL+fqDAYizQMNOLW2WcksFt9iHA0YdOTzo13yEUjH /g==
Received: from crk-mailsvcp-mta-lapp02.euro.apple.com (crk-mailsvcp-mta-lapp02.euro.apple.com [17.66.55.14]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3bq3xu9jp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <sframe@ietf.org>; Fri, 15 Oct 2021 10:05:48 -0700
Received: from crk-mailsvcp-mmp-lapp02.euro.apple.com (crk-mailsvcp-mmp-lapp02.euro.apple.com [17.72.136.16]) by crk-mailsvcp-mta-lapp02.euro.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R110036C3HM7E00@crk-mailsvcp-mta-lapp02.euro.apple.com> for sframe@ietf.org; Fri, 15 Oct 2021 18:05:46 +0100 (IST)
Received: from process_milters-daemon.crk-mailsvcp-mmp-lapp02.euro.apple.com by crk-mailsvcp-mmp-lapp02.euro.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1100D0034E0X00@crk-mailsvcp-mmp-lapp02.euro.apple.com> for sframe@ietf.org; Fri, 15 Oct 2021 18:05:46 +0100 (IST)
X-Va-A:
X-Va-T-CD: 82d136be8d29894cd8ebb4823be734da
X-Va-E-CD: 32226c6fd1ca3a0f8cf3bf4b30472e4a
X-Va-R-CD: 66c2a1cf38dce55cd8b43932d6aed894
X-Va-CD: 0
X-Va-ID: 9de5bcf0-4bb7-40ad-a9de-7fafc53eb4a5
X-V-A:
X-V-T-CD: 82d136be8d29894cd8ebb4823be734da
X-V-E-CD: 32226c6fd1ca3a0f8cf3bf4b30472e4a
X-V-R-CD: 66c2a1cf38dce55cd8b43932d6aed894
X-V-CD: 0
X-V-ID: b9d3bdbe-ec57-4189-9131-1d2b1fdc1d94
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-15_05:2021-10-14, 2021-10-15 signatures=0
Received: from smtpclient.apple ([17.235.205.147]) by crk-mailsvcp-mmp-lapp02.euro.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R110056O3HJJM00@crk-mailsvcp-mmp-lapp02.euro.apple.com> for sframe@ietf.org; Fri, 15 Oct 2021 18:05:46 +0100 (IST)
From: Youenn Fablet <youenn@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_7822907F-2EC3-4A9B-96DD-4BBF37E5F728"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.21\))
Date: Fri, 15 Oct 2021 19:05:41 +0200
References: <7e721f57-e7ee-4f47-8663-2b485aeabd1a@www.fastmail.com> <CAL02cgRGJGuzCnG0Abi-ztMgKWi+gN4je4BmAF0p0mYCDxWhWQ@mail.gmail.com>
To: sframe@ietf.org
In-reply-to: <CAL02cgRGJGuzCnG0Abi-ztMgKWi+gN4je4BmAF0p0mYCDxWhWQ@mail.gmail.com>
Message-id: <DDA50D9F-550C-4CAB-ABD0-6D8CD2B91632@apple.com>
X-Mailer: Apple Mail (2.3693.20.0.1.21)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-15_05:2021-10-14, 2021-10-15 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/h_wFY5MrccEroZ-bke02hvDy6y4>
Subject: Re: [Sframe] Adoption call for draft-omara-sframe-01
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Media Frames <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Oct 2021 17:05:55 -0000

I support adopting this draft as a working group item.

The SFrame format, or variants of it, are being deployed in existing applications.
This gives confidence in the fact that the SFrame format described in the document is solving real problems.
The current draft document allowed to implement it in at least two independent implementations (Cisco and Safari), both implementations passing the same test suite.
This gives confidence in the level of details used to describe the SFrame format.

I look forward for additional work in the area, to address Bernard’s points and more.
The suggestion to move part of the current document in a separate document seems a good idea.
This modularity would for instance be useful in W3C specifications building on the SFrame format, in particular the being standardised SFrameTransform.

I do not think that this is a blocker for adopting the document as is.
Adoption by the WG is just a starting point, and I believe that contributors of this document are aware that more work is needed.

Thanks,
	Y

> ---------- Forwarded message ---------
> From: Martin Thomson <mt@lowentropy.net <mailto:mt@lowentropy.net>>
> Date: Sun, Oct 10, 2021 at 7:36 PM
> Subject: [Sframe] Adoption call for draft-omara-sframe-01
> To: <sframe@ietf.org <mailto:sframe@ietf.org>>
> 
> 
> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01 <https://datatracker.ietf.org/doc/html/draft-omara-sframe-01>
> 
> Please respond to this email before AOE 31 October 2021 if you support adopting draft-omara-sframe (currently -01) as a working group item.  If you would prefer we not adopt this work, please respond with an explanation of why and ideally what you would like to see addressed before we do that.
> 
> We're running this a tiny bit longer than a typical adoption call.  Last time we talked about adoption there were a few concerns raised about the draft.  We want to make sure those concerns are addressed, or at least those with concerns are satisfied that their concerns could be addressed.
> 
> Martin, for the chairs
> 
> -- 
> Sframe mailing list
> Sframe@ietf.org <mailto:Sframe@ietf.org>
> https://www.ietf.org/mailman/listinfo/sframe <https://www.ietf.org/mailman/listinfo/sframe>

v2.23.0 | Report a Bug | By Email