IETF Logo Mail Archive

Re: [pim] Éric Vyncke's No Objection on draft-ietf-pim-igmp-mld-extension-06: (with COMMENT)

Lars Eggert <lars@eggert.org> Thu, 03 February 2022 10:08 UTC

Return-Path: <lars@eggert.org>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074333A0D46; Thu, 3 Feb 2022 02:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=eggert.org
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 WHrmIcNZDFvs; Thu, 3 Feb 2022 02:08:45 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 6D1D53A0D44; Thu, 3 Feb 2022 02:08:45 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:3483:e6e7:fbe7:7efc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 4CBE91D4322; Thu, 3 Feb 2022 12:08:32 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1643882912; bh=8O3mirLw6mU/I5HiSnQFe+nK2do4/RXbtDDc4NMhNPM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B8VZazrPL97M6vqNFUtQAraMT07IeK93TuNFBMBRqIspOKaBfjenC1zhSF77Ppr3x bUjOnWVe7dbGXzXagI70q3Qof0Hq4TsWVc2f+sfaObgvp92dQIXOFqQPOvjZSdf+Wh aMF3hDUgl4oOr7Rhm82aYfJQSnkksPQLrrBVJTbg=
Content-Type: multipart/signed; boundary="Apple-Mail=_FBF88C19-4502-4E36-8D43-322256755BC7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <CAMMESswHR8qnMgC7ktG8rDDbp=P+=v_CKmz+S9vFcp7eAeq7iQ@mail.gmail.com>
Date: Thu, 03 Feb 2022 12:08:31 +0200
Cc: Éric Vyncke <evyncke@cisco.com>, mmcbride7@gmail.com, pim-chairs@ietf.org, draft-ietf-pim-igmp-mld-extension@ietf.org, pim@ietf.org, The IESG <iesg@ietf.org>
Message-Id: <173AC174-15BD-44FA-8148-B5D1831B13DE@eggert.org>
References: <164364051519.21164.246935898257729898@ietfa.amsl.com> <CAMMESswHR8qnMgC7ktG8rDDbp=P+=v_CKmz+S9vFcp7eAeq7iQ@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
X-MailScanner-ID: 4CBE91D4322.A499A
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/9XrUcDBJ5dWWQ5Q3ya9HpzxSILE>
Subject: Re: [pim] Éric Vyncke's No Objection on draft-ietf-pim-igmp-mld-extension-06: (with COMMENT)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2022 10:08:50 -0000

Hi,

On 2022-2-1, at 20:56, Alvaro Retana <aretana.ietf@gmail.com> wrote:
> The WG had a specific discussion about formally Updating
> rfc3376/rfc3810 and decided against it.  In general, the consensus is
> that this new mechanism is not a required extension of IGMPv3/MPDv2.
> Among other reasons, as explained in §5, host implementations change
> very slowly, and the use of the E-bit is backward compatible.

that's all true, but AFAIK there is no registry for these bits and if there is no formal "Updates" relationship, we need to rely on the community somehow remembering that this bit was assigned for this RFC-to-be, to avoid clashes with other future extensions?

Thanks,
Lars

v2.23.0 | Report a Bug | By Email