Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring) and RFC 8889 (Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring)to Proposed Standard

Barry Leiba <barryleiba@computer.org> Mon, 30 August 2021 18:20 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CF13A1CD0; Mon, 30 Aug 2021 11:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 BwrJtzZ2wvrJ; Mon, 30 Aug 2021 11:20:20 -0700 (PDT)
Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (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 4C4623A1CCC; Mon, 30 Aug 2021 11:20:20 -0700 (PDT)
Received: by mail-lf1-f51.google.com with SMTP id g13so32998587lfj.12; Mon, 30 Aug 2021 11:20:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8pKDXe/QjZuNeBCm2ghxhT1+lN6RAHvIjEXskEZMtDs=; b=DZpULD8ShYdIIHGp2Mx21zJ6kNytyA81pzB+cUTbuE0uVpSEU9flwnqCBrZO94BQVT b4qJDot1+7B348X9RDYMwoPYwhGq61rcS3d7J6g1LuqzzFvDb+OQiBKI8SAtI5BWt2gJ 54Fn2VmAbleNGOSZrqTb2DdUAbZ4DLxjrKI8L3ClQNoYxUvlK/CFqk+6vfj64f6BvprP WpL+Rvwsr82N92cixwd4ApHsLLDPlyiQGCvyC3E2yjTMhYT5eGkCzlH+KwB2UouUs+dl A3vF+OeHzzeVX2OOj168kOwAuNyExurIkKr8ltvm7R/8ne4CWHrGAdIIi9CwuCC/c+e+ aizQ==
X-Gm-Message-State: AOAM531MICFAtNnB3MZPkne6CAiKe6G1JXFeEsU4xJoi2KnWbu9KVOyD aTmN5taGPkLjlEX8wawdOYtEURZKQJe+eD+mQhc=
X-Google-Smtp-Source: ABdhPJyiGHy2rVwM0zSNupr0eRfNPPPtoRDJx+I3HuEcRT7lfW04bJKK9e9pit/kIU67U0IGEz3uedUEOKOB85INGUY=
X-Received: by 2002:a05:6512:32c6:: with SMTP id f6mr17574193lfg.292.1630347617930; Mon, 30 Aug 2021 11:20:17 -0700 (PDT)
MIME-Version: 1.0
References: <163009842725.17742.16380067018932520158@ietfa.amsl.com> <C852F58C18C7524F5478521E@PSB> <283542a3-3d19-dad3-a385-b99bb88dad19@gmail.com> <BA07E4B42541B5A6542970D4@PSB> <1c4c7401e33e4e70b1168b95288b543f@huawei.com>
In-Reply-To: <1c4c7401e33e4e70b1168b95288b543f@huawei.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 30 Aug 2021 14:20:06 -0400
Message-ID: <CALaySJL6NR5Xc=jNWz8qGEV8RSuE4ztOduuiAxmQUiESNvQrSw@mail.gmail.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: John C Klensin <john-ietf@jck.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "last-call@ietf.org" <last-call@ietf.org>, IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/RSyH0qpUhEhTtKVPgG_nBYJ93uw>
Subject: Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring) and RFC 8889 (Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring)to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2021 18:20:26 -0000

Thanks for the background information, Giuseppe.

To be clear, none of us who have commented are saying that we don't
think RFCs 8321 and 8889 are ready to move to PS.  We're just saying
that the "status change" mechanism isn't the appropriate way to do it,
and that it should be done with new I-Ds that go into IETF last call
through the normal I-D process.

Barry

On Mon, Aug 30, 2021 at 1:01 PM Giuseppe Fioccola
<giuseppe.fioccola@huawei.com> wrote:
>
> Hi All,
> I just want to clarify the background. The debate started since draft-ietf-6man-ipv6-alt-mark has been submitted to IESG for publication as Proposed Standard. To avoid downref, the current solution adopted in draft-ietf-6man-ipv6-alt-mark was to take some text from RFC 8321 / RFC 8889 and move into draft-ietf-6man-ipv6-alt-mark so that it can be elevated to PS.
> But this approach was considered suboptimal during the IESG evaluation and it was proposed to elevate RFC 8321 and RFC 8889 to PS.
>
> Regarding the maturity of RFC 8321 / RFC 8889, I want to add that the experiment, started in 2010, is now done. Indeed Alternate Marking is implemented by vendors (e.g. Huawei, Cisco, ZTE, Broadcom..) and deployed by operators (Telecom Italia, China Mobile, China Unicom..) as also confirmed by the answers to the poll launched by Martin Duke two weeks ago on the IPPM mailing list.
>
> Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: last-call <last-call-bounces@ietf.org> On Behalf Of John C Klensin
> Sent: Monday, August 30, 2021 6:25 AM
> To: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Cc: last-call@ietf.org; Barry Leiba <barryleiba@computer.org>; IESG <iesg@ietf.org>
> Subject: Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring) and RFC 8889 (Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring)to Proposed Standard
>
>
>
> --On Monday, August 30, 2021 14:23 +1200 Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> > I also strongly concur. It is very close to trivial to issue these two
> > documents as I-Ds with standards track boilerplate and give them a
> > 4-week last call. That would conform to our process and avoid an
> > extremely confused and confusing end state. A report on their
> > experimental use would be a useful adjunct to that last call.
> >
> > Maybe it would be quicker to use the normal downref mechanism, since
> > draft-mirsky-bier-pmmm-oam wants it.
>
> Brian,
>
> A downref to a standards track document, especially one we believe is stable (and maybe even deployed and interoperable) but that no one has gone to the effort to advance is one thing.
> Maybe I'm being over-rigid, but a downref to an explicitly experimental document without even an experimental outcome report seems to violate basic principles about stable references.
>
> AFAIKT, no Last Call has been issued on draft-ietf-bier-pmmm-oam (formerly draft-mirsky-bier-pmmm-oam).  Why not just spin up I-Ds to replace RFCs 8321 and 8889 and do this in an orderly fashion?
>
>    john
>
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call