[ippm] RFC 8321 and 8889

Martin Duke <martin.h.duke@gmail.com> Thu, 12 August 2021 18:26 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7AA383A4577 for <ippm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nVtZz8AO-9wd for <ippm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:26:32 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 8E5A53A4570 for <ippm@ietf.org>; Thu, 12 Aug 2021 11:26:32 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id y1so9636302iod.10 for <ippm@ietf.org>; Thu, 12 Aug 2021 11:26:32 -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:cc; bh=8hJSQPvvukjYUSnA1QzR+w0A/LidQoMMuyBhCIRWFuo=; b=abUbym8C73ERHXCEZOACiZhpdDVi1BsSYWSw7ty1J5NPDxIG3kkc3Qt6WjEXTiGvDW qdynUJH3wxEASZvFEEWwbk2JVdgIkLddyUhHVW7T4uV1mbEmfp0VtjG26tk6aona2q6J L6hqFEuWBubrGljrXos1vyrbCto8xb+/jSYc0d9nGsbPz8f0ZN62pU7MchQXZ43IrulZ lfdoaIPbUSm4+831OhQ6kYenkKk3W0wxvVMtaz85ocJZSzsKx7yBQw7GTnbVxhFdMWzo Jm0a+Uci3YDMiBz1qpWaoxPkzREcP7E3P04IDeyy0tX6sNbTymxrYG6a4UWJrsXz8VtT zy4A==
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:cc; bh=8hJSQPvvukjYUSnA1QzR+w0A/LidQoMMuyBhCIRWFuo=; b=KET0svGER8c+2dD9zy3H2MB8DQJQIkWeskLKzAzUeuYVHHyhnZbHTKtldbyaXYt/iC h0nqeNtl5t39GZscJK3GTxPRKRAeu2oDCgskbr4/hILZ7CkV8d1aIPyGKSVMEPbNzBzn 1CcPDYPQDj5VJdY4F0J2vHnUB+93uMGem5mF4g+6ktMupCZfhczEwCMuD6YKPWyTE/G9 Mr0Wdhu0QpmTlhNiJD+i1XoZxdkvvwlcT8J8XoYoROEGAqyONcNUFddJIezIJDIXpFCF IThj6LYcx6c1qFervPr71pqeKzfAoO22btYH3x92Q1p/qnRYwaj0izz7XX618Tke2F7w h3og==
X-Gm-Message-State: AOAM532WxIrCkl9Dp94NCVZyvsCI6LzKALKAW7KLjEtfVvxzMqgrfZAK RJJWOaRCdEuJkWL9UM4YNfiBGSftrn/Smh1GmyDlRQODHRc=
X-Google-Smtp-Source: ABdhPJzlcEzQ2+zW28YqEcqzfGEg2wwmrMETZd1Qp13peE0PZ1xZGg1tznKoe9OlD/KCmT/wPwKnvfaxJng/peF/XMs=
X-Received: by 2002:a05:6602:2003:: with SMTP id y3mr3961323iod.95.1628792790390; Thu, 12 Aug 2021 11:26:30 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 12 Aug 2021 11:26:19 -0700
Message-ID: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
To: IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af1d3905c960df7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/U-gy4T5XxfxIkdmMK-hWaeRKHwY>
Subject: [ippm] RFC 8321 and 8889
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2021 18:26:39 -0000

Hello IPPM,

(with AD hat on)

The IESG is currently considering
which is the implementation of RFC 8321
<https://www.rfc-editor.org/rfc/rfc8321.html> and 8889
<https://www.rfc-editor.org/rfc/rfc8889.html> techniques in an IPv6
framework. IIUC, this is very much how things are "supposed to work" --
measurement definitions and methodology are done by IPPM, and the
protocol-specific instantiations are in the respective working groups.

However, there are complications in that 8321 and 8889 are Experimental
RFCs, and the ipv6-alt-mark draft is a Proposed Standard. This has resulted
in text from 8321/8889 going into ipv6-alt-mark so that it can be elevated
to PS. I'm told that, if the status quo holds, other drafts will reference
ipv6-alt-mark to avoid a downref. This seems suboptimal.

I would prefer that *we take one of the two following actions*:
1) If the WG has consensus that we are comfortable that there is enough
experience with 8321 and/or 8889 to elevate them to PS, I can initiate a
document action to change their status.

2) If there is no such consensus, ipv6-alt-mark should be Experimental.

In either case, the draft can probably lose some of the duplicate text.

Logically, there is a third option -- that the bits of the RFCs copied in
the draft are mature enough to be a standard, but that the others aren't.
Though I'm not an expert, I doubt this is the case. But if people believe
it to be true, we'll have to come up with new options.

I would be grateful for the working group's thoughts about these documents
and the ideas therein. Is it reasonable for people to read and reflect on
this by 26 August (2 weeks from today?)