[Pce] Re: 答复: New draft to update IANA registration policy

Dhruv Dhody <dd@dhruvdhody.com> Thu, 25 July 2024 12:51 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2DC1CAE9A for <pce@ietfa.amsl.com>; Thu, 25 Jul 2024 05:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20230601.gappssmtp.com
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 2jzAjS1Rfb3t for <pce@ietfa.amsl.com>; Thu, 25 Jul 2024 05:51:06 -0700 (PDT)
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B9817C1EBF2C for <pce@ietf.org>; Thu, 25 Jul 2024 05:51:06 -0700 (PDT)
Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-5d4fb707895so539748eaf.0 for <pce@ietf.org>; Thu, 25 Jul 2024 05:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1721911865; x=1722516665; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+KaqBITMNNBqoIKVZDQ4e/R1JtbkS+qBdF+d7HFfkp4=; b=YC2b0PNGxOhnfE0vJQO2L913YauMq6e9nTiv/1MJlqig86A3XbB6hgzBqMWQtvItIo nRB3jgtf/DLDknUkJEkwXsuWD5o1orZGHOzK4jieQVCYDzjBp/yjj+Nf9O9kwatN0SVK XSnwWhzSKxikxqVaredkwmwcmopmdRMV6kQXA2skpEsVbUnCvOxnw8rH6hpKzBBDmajs gK5galjfc/Rrg+DzzqfHvNOoq/ZFC0GR2yLcJgWseiMgyWnoyzd/iXbou7s3Fbxt7/PE Gr7ThxeQrsk/ZmBLkRDUuMRUcoTHMCf0L9fXFh/wLtT6Sw04G+8B3m3VLqNCsUlJE1Bq tSvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721911865; x=1722516665; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+KaqBITMNNBqoIKVZDQ4e/R1JtbkS+qBdF+d7HFfkp4=; b=WgOaDCNGalto+wrBtxGr0M1rp+5b3QHoF80lrRvm3ruSUBPYbe959yeRscRJCDd3op m533L6a21T4dZxu9XKyEdMNXR4TzmFu/euIoeAObkaLMZ/FjVmwZQoqSsMkFBGVn6R6i jLvPKqWnCcLZdps1mqjnOCNZQUp09LoqcyR23haLQhGiCZpXzuOsg2smNoYOd8KZ7nP7 DOUYt8lav4W//cEORGt36LMCbyMavsFBXZwfggw6eIQsmoRDlwXf77fL9a8kpfPTVgud HxO7eJA0zLJIWDNtto26thT3Z+Spti4UrUSqXnFmORO0NZc7xOU5U0FeJlW2BnDRi2cI 7w3A==
X-Gm-Message-State: AOJu0YyRv6O3AsQaIHmP0vKRMwej0i4jh753ZFhbSwLzP5nl8+YsQA9b yZYkPfKqPvqu1G8enveY/hZ9wkUkTjX653MS/NE/4G1boGUvmY8UD9XHXpfqgHPxs7aBuDyOIrX VnDlWZ52T145/hEIODSiQnx+lYWVWiPEGpNY7ZA==
X-Google-Smtp-Source: AGHT+IE2cagP3eZhsbm1/KO5UoE4Zrg1AEyEZlxUtzngbwXWDOOpBvmhcoUr8d9wJiZa3hOR/72MGQdfAE4xjMD566c=
X-Received: by 2002:a05:6820:1b09:b0:5cf:24e0:b78 with SMTP id 006d021491bc7-5d5adac7d98mr3611855eaf.3.1721911865533; Thu, 25 Jul 2024 05:51:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5a4tnoG7qaRDyBmtnXDosqQnn=OibVMRo211FpwW63Mvg@mail.gmail.com> <000001dade6a$fb389520$f1a9bf60$@tsinghua.org.cn> <IA0PR11MB77922DEB58CEBDBF0B3EDEF3D0AB2@IA0PR11MB7792.namprd11.prod.outlook.com>
In-Reply-To: <IA0PR11MB77922DEB58CEBDBF0B3EDEF3D0AB2@IA0PR11MB7792.namprd11.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 25 Jul 2024 05:50:29 -0700
Message-ID: <CAP7zK5aunYCMwQQGty80i+BgS-kjK_Bjc4QXVNRasy5HbW2Vwg@mail.gmail.com>
To: "Samuel Sidor (ssidor)" <ssidor@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000147f2c061e11d96e"
Message-ID-Hash: OMKH6SUQAFFO24YOJO264H6UPM32FP5P
X-Message-ID-Hash: OMKH6SUQAFFO24YOJO264H6UPM32FP5P
X-MailFrom: dd@dhruvdhody.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "pce@ietf.org" <pce@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: 答复: New draft to update IANA registration policy
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/4MJDFYNcPruA9gNjpEsj-zLOvBg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi Samuel,

On Thu, Jul 25, 2024 at 1:28 AM Samuel Sidor (ssidor) <ssidor@cisco.com>
wrote:

> Hi Dhruv,
>
>
>
> I support change itself.
>
>
>
> One comment for note/question in the draft:
>
> Question to the WG: The current document updates all
>
> the registries. Should we keep "Standards Action" for
>
> some of them such as flag fields with limited bits?
>
>
>
> I’m personally not worried about that. We should be able to use same
> approach as used for LSP object flags.
>
>
>
> One exception, which I can think of are fixed size objects, which may not
> be allowing TLVs currently (I’m not sure if there is any specific example
> in the list of registries). Do we have any specific plan for those?
>
>
>

I did a quick manual check. We mostly dont have this problem with one
exception of flag fields in sub-objects.

Things to note -
- there are already some subobjects flag field that are IETF review
- some of these have reserved fields that can be easily used
- we could extend by creating a new sub-object type if needed

Thanks!
Dhruv



> Thanks,
>
> Samuel
>
>
>
> *From:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Sent:* Thursday, July 25, 2024 10:17 AM
> *To:* 'Dhruv Dhody' <dd@dhruvdhody.com>; pce@ietf.org
> *Subject:* [Pce] 答复: New draft to update IANA registration policy
>
>
>
> Hi, Dhruv:
>
>
>
> Thanks for your quick draft. I think IETF review is enough because the
> required RFCs needs to be passed all the same stages
>
> Although there maybe some different criteria, the related RFCs can assure
> the interoperability of protocol from different vendors.
>
>
>
> The document is written clearly. If there is no objection, we can move it
> faster to be published.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人**:* forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org
> <forwardingalgorithm@ietf.org>] *代表 *Dhruv Dhody
> *发送时间:* 2024年7月23日 5:19
> *收件人:* pce@ietf.org
> *主题:* [Pce] New draft to update IANA registration policy
>
>
>
> Hi,
>
>
>
> I have written a small draft to update the registration policy for all
> "standards action" to "IETF review" for PCEP registry.
>
>
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/
>
>
>
> The approach that the draft currently takes is to make a blanket change to
> IETF-review for all "standards action" registry to allow experimental track
> documents to request allocation. There are some registries where the space
> is tight but IMHO IETF-review is fine -- our WG and LC process should be
> enough to handle the case of less bits which ideally require creating a new
> field/registry as we did in the past for LSP object flags!
>
>
>
> Thoughts?
>
>
>
> It might be a good idea to move this quickly as John suggested in his AD
> review of Native-IP draft [1].
>
>
>
> Thanks!
>
> Dhruv
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/xBn2_9E9vy6h5AnYEMMf3I9vbqM/
>