Re: [Sat] SATP Core document has expired

Wes Hardaker <wjhns1@hardakers.net> Wed, 24 January 2024 21:33 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: sat@ietfa.amsl.com
Delivered-To: sat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013DEC151095 for <sat@ietfa.amsl.com>; Wed, 24 Jan 2024 13:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaKjA133ax5Z for <sat@ietfa.amsl.com>; Wed, 24 Jan 2024 13:33:29 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D75C151094 for <sat@ietf.org>; Wed, 24 Jan 2024 13:33:28 -0800 (PST)
Received: from localhost (unknown [10.0.0.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 7E61B26B49; Wed, 24 Jan 2024 13:33:28 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 7E61B26B49
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1706132008; bh=65F0GALUV/2Jz+xABLsuPwnUTZA6gMmKIfuf1U89RbQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KDqyY1CHEc6nmYdnvJrYUCbKm+DUJsC74cwsnkjNZRqzJrBZ+IGvBBvECfkOkEc3F QvAs0avx72MNFUpXLh1xQjUefsRvr8WU+YsnXk+e/AuBh10OO6mVPPglFc885Vlbeq yQnmFYMElWUlsoptHT+s5asj77sT7LeCwak7NjTU=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Thomas Hardjono <hardjono@mit.edu>
Cc: VENKATRAMAN RAMAKRISHNA <vramakr2@in.ibm.com>, Rafael Belchior <rafael.belchior@tecnico.ulisboa.pt>, "sat@ietf.org" <sat@ietf.org>
In-Reply-To: <DM5PR0101MB29562C901D2CF8A090E15364CB752@DM5PR0101MB2956.prod.exchangelabs.com> (Thomas Hardjono's message of "Mon, 22 Jan 2024 23:52:41 +0000")
References: <SJ0PR15MB5132D9DB7C2FC322998121D8B8752@SJ0PR15MB5132.namprd15.prod.outlook.com> <B04DEB0B-5DBB-476B-BA65-3F8D1C177412@tecnico.ulisboa.pt> <SJ0PR15MB51329F42E9C3CECE077B5BBFB8752@SJ0PR15MB5132.namprd15.prod.outlook.com> <DM5PR0101MB29562C901D2CF8A090E15364CB752@DM5PR0101MB2956.prod.exchangelabs.com>
Date: Wed, 24 Jan 2024 13:33:28 -0800
Message-ID: <yblplxq4dsn.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/sat/vhnx74jNy9hO0eeAo5BvpahnTJU>
Subject: Re: [Sat] SATP Core document has expired
X-BeenThere: sat@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "The purpose of this mailing-list is to discuss the secure asset transfer \(SAT\) protocol and related aspects." <sat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sat>, <mailto:sat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sat/>
List-Post: <mailto:sat@ietf.org>
List-Help: <mailto:sat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sat>, <mailto:sat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2024 21:33:33 -0000

Thomas Hardjono <hardjono@mit.edu> writes:

> I believe for a document to pass the WG Last Call, all normative
> references to IETF specs must be to RFCs (not to drafts).

This is correct.  Specifically, if there are normative references to
future documents, the RFC editor will hold up the publication of a
document until the rest of have caught up.
-- 
Wes Hardaker
USC/ISI