[saag] metadata insertion draft question

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 14 October 2016 15:59 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390F112985D for <saag@ietfa.amsl.com>; Fri, 14 Oct 2016 08:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.297
X-Spam-Level:
X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 L7sKFNRAhYif for <saag@ietfa.amsl.com>; Fri, 14 Oct 2016 08:59:24 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C7F129857 for <saag@ietf.org>; Fri, 14 Oct 2016 08:59:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70D9CBE38 for <saag@ietf.org>; Fri, 14 Oct 2016 16:59:20 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knUnvkcKnqLJ for <saag@ietf.org>; Fri, 14 Oct 2016 16:59:20 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C963FBE32 for <saag@ietf.org>; Fri, 14 Oct 2016 16:59:19 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476460760; bh=pREmAXT43gd8zoYbWRsr1opMx8IGNAp7Hxsw8XLOflg=; h=To:From:Subject:Date:From; b=AlpMXRQjXZmT41s41oz3iNlj1511Ct+G4sdB/6KM+h5qt6js2aWiJ+D2w1qGatZ/R DF8qak8RyA7ZOYnR/RvvCzOmIvz/nEY/6OwBNe9bMjMa7LNdLezUH+yAHRXN7eOeku FXuEx0t9yU1BxHw9LjqgWGfoq7Tlsp/pQbNSMv6s=
To: "saag@ietf.org" <saag@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <86bbe523-972b-772c-b002-dbdbbedc00c8@cs.tcd.ie>
Date: Fri, 14 Oct 2016 16:59:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070008050402050405040801"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/nPVREoq7bSF3lnoPqzBdSco4UP4>
Subject: [saag] metadata insertion draft question
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 15:59:29 -0000

Hiya,

Ted has written a draft [1] on this topic.

Earlier, we wondered whether it'd be good to include
the meat of this into the work on 3552bis. [2]

Ted's now at the point of thinking his draft is near
done so would like to know the plan.

If we seem to have consensus to include this in 3552bis
then that's straightforward.

If we think that's not the best plan, then I'd likely
look at AD sponsoring this separately to see if it has
IETF consensus.

So, what do you think, should we:

a) incorporate the meat of [1] into [2]
b) look at AD sponsoring [1] separately
c) something else...

Thanks,
S.

PS: Note that your answer to the above does not have
to mean you think the text in [1] is perfect. An IETF
last call will be needed for either (a) or (b) when
any changes needed can be identified.


[1] https://tools.ietf.org/html/draft-hardie-privsec-metadata-insertion-03
[2] https://tools.ietf.org/html/draft-nir-saag-rfc3552bis-00