Re: [ippm] Jim Guichard's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)

Martin Duke <martin.h.duke@gmail.com> Wed, 03 May 2023 14:28 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A551FC1516E3; Wed, 3 May 2023 07:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7HgBprZDvAge; Wed, 3 May 2023 07:28:48 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 CA0BFC15199D; Wed, 3 May 2023 07:28:40 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-430192c84a1so1949498137.1; Wed, 03 May 2023 07:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683124119; x=1685716119; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PnXI7v263BsowUUACiQJRDxiJn2Xy2wmPlV32+febGo=; b=pojpVd72TVsAhNiycMAFZc+6yAQ08V1DSXI9Ei21KXbRxTbLcH0bqBs/trlKWgBu8Z zwHj4QidUucyVAdv7vW0jL2aDqeLdaQ0ABnXMpJOK4NclfdDGwCdtKIKVDQ5XsIuBokS 1uFgLr2guejuCLACfGswfJq0mnaathpXLaac7KCeYPLjDTA5YZ1qDCVwRaKOhlJaXYvh CSSH5iRKd5c8mXYP5aW6m6FvYqZyV9zCCxPvPGeuxIsfNxPjWYo6vTsm1vvbvD9NBpt2 Xx+dwx2GJGG/adyKfKvLCZ8mxRQDGRmK7S3Q9pEJOeIqYSTbnFW8IPWo+XOQuktnW9sx ZxMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683124119; x=1685716119; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PnXI7v263BsowUUACiQJRDxiJn2Xy2wmPlV32+febGo=; b=i6x/9vxF9CaLcLSWQl7vV1JzGAqcCv3nmgL7eMWaQQgAVT9JPi8VjXJqy3pz2yrqqB nawEzD+Zuy0m+A4+RpHBZ1p5YQiToNoIdaZjvXXUqXzKTNsc/Mf3IDnbAjzJsmUWUwRh o7jEvErbPt+qWgAf8qKURA1GaYBZ5syaZoBxFwMJVDEwOGq+2ObSTpWZYsqjWBZgHMaE 8Ur6hA15RnHrHCE/IaQqLTHNHMcq7jjFAInD92M7ZTXefaJOukP0XEpC1ruReFCOllcF Anhese4/O8+N61vKd48eR8RxsN8TJ7X+xNY2oxtcwkKVG2SChAxAzxRaY2SwQbCH9fQI gh1g==
X-Gm-Message-State: AC+VfDwoRQLsLh41rqXWA5EkwO5HxtTFibb8/XpXmqlw9vP3HBOXdHTm vTk1B8EhoNRzZNZongM3x8au2ildhDHCFaaI3WQ=
X-Google-Smtp-Source: ACHHUZ5DG55D4vdqjjPh98UwpIHeEZYJcfKkvjStxYi0WDAeBC817hoZSvyJm9JlGIfemDJaPnwGZbIq29LJOVCYAQQ=
X-Received: by 2002:a67:ec4c:0:b0:434:64c4:b6eb with SMTP id z12-20020a67ec4c000000b0043464c4b6ebmr218240vso.7.1683124119432; Wed, 03 May 2023 07:28:39 -0700 (PDT)
MIME-Version: 1.0
References: <168295080384.49928.5675199861192112944@ietfa.amsl.com> <2a8f03570158437d96b669384886f1c4@huawei.com>
In-Reply-To: <2a8f03570158437d96b669384886f1c4@huawei.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 03 May 2023 07:28:25 -0700
Message-ID: <CAM4esxQWfUc-MG-LfccoBe++-7kA2omim1zEW4w2iDGOzNE7gQ@mail.gmail.com>
To: Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@dmarc.ietf.org>
Cc: Jim Guichard <james.n.guichard@futurewei.com>, The IESG <iesg@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "draft-ietf-ippm-explicit-flow-measurements@ietf.org" <draft-ietf-ippm-explicit-flow-measurements@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040736905facadff3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/FhmxmjsGWmWvH3BOiAchnHLhKYw>
Subject: Re: [ippm] Jim Guichard's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 03 May 2023 14:28:52 -0000

I do not support elevating this document to PS. Whatever normative bits
future standards want to use will have to be repeated in that document,
which is great because trying to implement this entire draft would be very
confusing.

On Wed, May 3, 2023 at 2:07 AM Giuseppe Fioccola <giuseppe.fioccola=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Jim,
> Thank you for your review.
> This is an informational document since we initially followed the approach
> of RFC 8321 and RFC 8889, which were elevated to standards track when the
> methods were considered more mature (i.e. RFC 9341 and RFC 9342). The bits
> used in both QUIC and TCP headers are just examples of experimentation.
> Indeed, this draft aims to define transport agnostic methodologies that can
> be theoretically applicable to any transport-layer protocols between client
> and server. Different techniques are included in this document, while the
> assumption is that the different standards track documents, which apply
> these methods to a specific protocol (e.g. QUIC, TCP, CoAP,…), will
> consolidate the design into fewer bits according to the application
> scenarios. A first example is
> https://datatracker.ietf.org/doc/draft-ietf-core-coap-pm/.
> I agree with you that a standards track document would avoid any possible
> objection about the DOWNREF of future documents, but I do not know if there
> is the consensus of the WG to change the intended status to standards
> track. Maybe this could be verified with a poll. Moreover, it is also worth
> highlighting that some of the methods described in this draft are already
> proposed standards: Q bit is described in RFC 9341 while S bit is
> introduced as an optional feature in RFC 9000.
>
> Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: Jim Guichard via Datatracker <noreply@ietf.org>
> Sent: Monday, May 1, 2023 4:20 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-ippm-explicit-flow-measurements@ietf.org;
> ippm-chairs@ietf.org; ippm@ietf.org; marcus.ihlar@ericsson.com;
> marcus.ihlar@ericsson.com
> Subject: Jim Guichard's Discuss on
> draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)
>
> Jim Guichard has entered the following ballot position for
> draft-ietf-ippm-explicit-flow-measurements-03: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-explicit-flow-measurements/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I am wondering why this is an informational document when it uses reserved
> bits
> from both QUIC and TCP headers (?). If those reserved bits are used by the
> mechanisms described in this document but there is no "official"
> allocation of
> the bits then future documents that wish to use these bits will be limited
> and/or clash with an Informational RFC. Adding a DISCUSS as although this
> is
> not a technical area of expertise for me, it seems unusual and I would
> like to
> better understand the document track selection.
>
> I also do not see a transport area directorate review and in fact the
> document
> shepherd highlights that the document could benefit from such a review.
> Given
> that the bits introduced in the document are suggested to be carried in the
> QUIC and TCP headers using their reserved bits, then a review by the area
> responsible for those transport protocols seems mandatory.
>
>
>
>
>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>