IETF Logo Mail Archive

Is the invariants draft really standards track?

Martin Duke <martin.h.duke@gmail.com> Tue, 26 May 2020 17:55 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD33A0808 for <quic@ietfa.amsl.com>; Tue, 26 May 2020 10:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6JpJ9TirJplp for <quic@ietfa.amsl.com>; Tue, 26 May 2020 10:55:29 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D793A07F5 for <quic@ietf.org>; Tue, 26 May 2020 10:55:29 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id r2so12713790ioo.4 for <quic@ietf.org>; Tue, 26 May 2020 10:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JuqkFcChNTjBQdkNpmr4dF3PkE4CX6oP/6P9HR0L5vc=; b=skg2UPV+KVkox0eFTGSX04sFp7cl/OTQPnmvcLub7XChVXhubnHR3Gl0l8620E5Szu tVAumjj3BLLftzPCR4lAqObY0HER9/jozReOOcDm/bW15d7TkuFjF8b29COePcyoyHCZ 6MqUWht4czSrFaeR9WOFOtOquPjyMhF0JKLbPZRJVjYy49+O/R726R9Qgfh2TYPUrVFx 1jmuAqWlrdLDT/T5xtZLphSbA3JSeHfQ/y8tVoYYpxEtFExWivVEvwDnb5owWnTgo+n/ 82XS2M56iB6OK2lbGqu0CVj9sF0GAR2EBiTSQF2GruyZdxin79ir/OJZDqj36oqsOBGO G9LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JuqkFcChNTjBQdkNpmr4dF3PkE4CX6oP/6P9HR0L5vc=; b=B0g9Cq/zV+JeTe8VFECnSOi7jU6jIHmYhYVoGzvGrZggchJNi3YUh+qZ9ABrit9XnG qVX+VL25jUvxPfjQJtDpTv86voV9vH1lNrMaYFPhLD6BtclrvHR7znywa/i6TL6ihZdN xBpKQVbU5CS1uTpnzBY75kRJ1hG+ESD0Mi292XPdBU8zoB/9EID8TQpin6ZYwWH7V9yd Nc/yNpXg5yWAtxNjKH6QeC+4R+jTaOez7EARioNdXJbBdc/6paS5yw4fmFCskPcQqXui PUTdIp5loYpNEImngKUlIKdB8Ahje2YNFTghO5MRgJCw8FZj8s/gRyCpyUb+RF24KwrJ wJ/w==
X-Gm-Message-State: AOAM532XorVdDTAaqB226FzCUvGSBhs6Iu0zSU8mbIfiK3ae8Kkd0tcx svhL/cQuGEBgC8XHSg5y6C2nSE+QB43HkL9hRTqbMULF
X-Google-Smtp-Source: ABdhPJwBHqau8RUcmp4nEmGwo51ovXyLMlTI8FoBK9O2NgpcxywSzqy4++ePxbZhZt3g9Oou/VcOKpQyYYhuVAqNRAw=
X-Received: by 2002:a6b:fd18:: with SMTP id c24mr2341885ioi.97.1590515728416; Tue, 26 May 2020 10:55:28 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 26 May 2020 10:55:17 -0700
Message-ID: <CAM4esxQBqfrz24riPQA_VGKcGp_TzW0pqb97KfFMtNdW9pUfDg@mail.gmail.com>
Subject: Is the invariants draft really standards track?
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000000836205a690cd99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Zmu9uAyutk-dAz5wdAUjktTvfek>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2020 17:55:31 -0000

The only RFC 2119 keywords in this document are related to Version
Negotiation packets, and I suspect these requirements might best be in the
quic-transport draft. (At the very least, the quic-transport draft should
refer to these normative VN requirements hidden in quic-invariants).

If there are really no normative requirements on future versions of QUIC
with respect to long and short headers, etc, than this really is an
informational draft to help middleboxes understand the current IETF
consensus about future versions of QUIC.

I would much prefer that either:
- This draft becomes fully normative on future versions of QUIC ("Future
versions of QUIC MUST NOT mess with this format..."), or
- We pull the VN normative text out of -invariants and make this purely
Informational.

What do others think?

v2.23.0 | Report a Bug | By Email