Re: [pim] Stig/*: draft-ietf-pim-rfc8736bis problem / suggestion

Toerless Eckert <tte@cs.fau.de> Wed, 08 March 2023 22:33 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 3C7FEC1527A0; Wed, 8 Mar 2023 14:33:02 -0800 (PST)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 EnEI6Fu0wgiR; Wed, 8 Mar 2023 14:33:00 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 BDCCCC1522A0; Wed, 8 Mar 2023 14:32:59 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4PX6X52Gqhznkdj; Wed, 8 Mar 2023 23:32:53 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4PX6X51ZRWzkvGG; Wed, 8 Mar 2023 23:32:53 +0100 (CET)
Date: Wed, 08 Mar 2023 23:32:53 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: pim@ietf.org, draft-ietf-pim-rfc8736bis@ietf.org
Message-ID: <ZAkNFaNlGQrUxPwE@faui48e.informatik.uni-erlangen.de>
References: <ZAjV1SNf59DKMQY6@faui48e.informatik.uni-erlangen.de> <CAMMESswTGAqc=M7_q9Khad1uW8dv8yB=VjUxcVpY3mj+NKeNxA@mail.gmail.com> <ZAjsrzhY6o2Fv85s@faui48e.informatik.uni-erlangen.de> <CAMMESsy9HPriACfX1+E+ka5QXRVKoiCY8ZeszoB66j9RrK6WYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESsy9HPriACfX1+E+ka5QXRVKoiCY8ZeszoB66j9RrK6WYw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/kI1ekwsaDZc0ljcFp0UCnLrr770>
Subject: Re: [pim] Stig/*: draft-ietf-pim-rfc8736bis problem / suggestion
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 08 Mar 2023 22:33:02 -0000

I understand this since you mentioned "placeholder".
I still think it would be good to explicitly explain this in the text.

Example BCP picture showing how to represent the Flag Bits field
with one newly named/asked for bit and the text tha would go along with
it. And the IANA ask text.

There are thousand ways how this could be done. No need to have authors
wonder what the BCP way to do it is.

Cheers
    Toerless

On Wed, Mar 08, 2023 at 01:49:26PM -0800, Alvaro Retana wrote:
> On March 8, 2023 at 3:14:42 PM, Toerless Eckert wrote:
> 
> > On Wed, Mar 08, 2023 at 11:46:30AM -0800, Alvaro Retana wrote:
> > > On March 8, 2023 at 1:37:26 PM, Toerless Eckert wrote:
> > >
> > > The question about the actual bit position came up for
> > > null-register-packing during IESG Evaluation. As I explained then,
> > > the indication in the draft is just a placeholder.
> >
> > I am not aware that that this "placeholder" concept is specified
> > anywhere. Nor is that term or explanation used in either our drafts.
> 
> Sorry, I wasn't clear.
> 
> This is not a placeholder for the value in the registry.  The process
> still needs to happen to secure the allocation.
> 
> It is just a placeholder in the figure.  For this case, the allocation
> pattern is clear starting with FB 7, so it is a pretty good guess that
> IANA will allocate the next value.  Also, where it makes sense, IANA
> is open to recommendations.
> 
> Alvaro.

-- 
---
tte@cs.fau.de