From nobody Wed Mar 17 11:28:03 2021 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04BB3A105F; Wed, 17 Mar 2021 11:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CsCn_xH5GDE0; Wed, 17 Mar 2021 11:28:00 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 5B0323A105E; Wed, 17 Mar 2021 11:28:00 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id c10so4173420ejx.9; Wed, 17 Mar 2021 11:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 gmailapi.google.com 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)" , "draft-ietf-lsr-isis-srv6-extensions@ietf.org" Cc: John Scudder , "lsr-chairs@ietf.org" , "lsr@ietf.org" , 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-BeenThere: lsr@ietf.org 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 se= nt > 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=E2=80=99t= 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. =C2=A0If 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. =C2=A0As 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. =C2=A0I know Robert also cares about this topic, I hope others do too. Alvaro.