Re: [Lsr] When is an IANA Registry Required

Alvaro Retana <> Wed, 17 March 2021 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C04BB3A105F; Wed, 17 Mar 2021 11:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CsCn_xH5GDE0; Wed, 17 Mar 2021 11:28:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B0323A105E; Wed, 17 Mar 2021 11:28:00 -0700 (PDT)
Received: by with SMTP id c10so4173420ejx.9; Wed, 17 Mar 2021 11:28:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=l9UEIU9FeaVrjjlMIPdtQ6SwKKCvsdnPhXjzm01Foww=; b=mxMW78rqkwFtOTd3bM5l1+aeQfJ1L8RLJYAvfv2PcxQOT4i0XyWkT0iCOJGbsrpirC aCBVdnMOkqkBeJGeBWrS3yzQTPq9flLcS6c947r9OWoM7dsMEngaNYlADU2B5Mmzu3v8 gbrb/tmmSQfmx4cRL8JeT4dawLlv9B1M7QwcDb387nugB8bBLT7hkkEf3y/4O3d/dkFc iJcInUBvv+NaJjHBSJtb232tFLft61yQ6zhPdJNzYCZ8dXsJJL0CscLQ7JbZbTTwXgMg ld32Yx0T9YoK3bHfiZFy2B+WvRxeEjNw3OB9eU79V5Xv2K3ggveEl3zthrSvU78XRC81 DPHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=l9UEIU9FeaVrjjlMIPdtQ6SwKKCvsdnPhXjzm01Foww=; b=OY76jOzHIJIOZTaLMBAnrERDrB7NaEqNpqhU1oXz/9hPxJxoLdELyZqXfSF97qa3Ng HPpRWLxzLKunetP3E4PfWMKRoQCsYUlM3RInRk8ycLkGukxHF1U8s4G1GL7nI3AUNal+ fqB+V2PCei78doYFJz9Bdd1W7Ba48sIk0x3vGp00YWFA06v4jv0WQJ8de7TolpLGgavl qf+nf8XQMEkY1bp/9by8khBKueROm/MvaByPRKAPge42KVo6/WQr5t1QwqiFM1JYZoAi QwfKztAsGLUgCHTpAp3ZQcqbmmnUTeN6dvP9f78dWKzhj/ZXhUmUy2c/3Gn3UQzREyDm Jpwg==
X-Gm-Message-State: AOAM532lD8bjlSKJhbjLe7D77cUhb6WZWSY4bUJjGHpk+5tAK6rY1ZIS oj3ApnPpXM/dd8uKKGkDziD5JdxkhUO27suvf9s=
X-Google-Smtp-Source: ABdhPJzmg7vy8XjScmv2coJ4dAJShp5taOJ1kcqpXBrHfsWOJ6+kzjW7NOl0FYbbkrEQTnf7e289KvADDWcDvxrxgqo=
X-Received: by 2002:a17:906:1c13:: with SMTP id k19mr37155999ejg.457.1616005678938; Wed, 17 Mar 2021 11:27:58 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 17 Mar 2021 11:27:58 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Date: Wed, 17 Mar 2021 11:27:58 -0700
Message-ID: <>
To: "Les Ginsberg (ginsberg)" <>, "" <>
Cc: John Scudder <>, "" <>, "" <>, Christian Hopps <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Lsr] When is an IANA Registry Required
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Mar 2021 18:28:02 -0000

On March 17, 2021 at 12:25:25 PM, Les Ginsberg wrote:

> > In the extreme case anyone can make use of the bits, through the ISE
> > or a different SDO -- ideally we will be paying attention, but may
> > not. Sure, a registry doesn't stop implementations from squatting on
> > codepoints either (even inside the IETF), but at least people have to
> > want to bypass the allocation rules.
> >
> [Les:] When a specification says "all other bits are reserved, MUST be sent
> as 0 and MUST be ignored on receipt", I do not see how anyone can assume they
> can use them - nor why the existence of a registry would prevent such a
> squatter from doing whatever they want outside of normal channels.
> Are you suggesting that normative statements in RFCs simply don’t mean
> anything?

Not at all!

The "MUST send as 0 and MUST ignore" text is normally used when the
application of those bits has not been defined.  If you define the use
of one of the bits then you will obviously set/not ignore it, whether
it has been defined in an ID/RFC or not.  As I said, "a registry
doesn't stop implementations from squatting on codepoints either (even
inside the IETF), but at least people have to want to bypass the
allocation rules."

I don't know that you and I are getting anywhere.  I know Robert also
cares about this topic, I hope others do too.