Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 15 July 2021 17:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55A83A1532; Thu, 15 Jul 2021 10:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 CknMsPBNeOYz; Thu, 15 Jul 2021 10:52:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD29F3A1528; Thu, 15 Jul 2021 10:52:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 90AC238A94; Thu, 15 Jul 2021 13:55:13 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PzJR62rnmWWR; Thu, 15 Jul 2021 13:55:09 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5276E38A89; Thu, 15 Jul 2021 13:55:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E8E4D641; Thu, 15 Jul 2021 13:52:06 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org
In-Reply-To: <162634134491.20957.9891384677904460366@ietfa.amsl.com>
References: <162634134491.20957.9891384677904460366@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 15 Jul 2021 13:52:06 -0400
Message-ID: <2247.1626371526@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/3A5BofhP85b7I7rL02os4J5bxzM>
Subject: Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2021 17:52:19 -0000

Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> wrote:
    > *Section 3 : says -

    > "The creation of this new version of the ".sid" file
    > SHOULD be performed using an automated tool"

    > If this is supposed to be the automation process written in appendix B then
    > putting a reference here makes sense. If not, then as this is very important
    > tool, more information need to be added here in this specification (like,
    > where to find it, who create and maintains it, any reference to such an
    > existing tools). Also I am missing what consequences one need to consider if
    > the process is not automated. If this is same as written in the
    > introduction -

it's in pyang 2.1 since late 2019.
I don't know what the current practice towards referencing pyang.

    > "Assignment of SIDs to YANG items can be automated.  For more details
    > how this can be achieved, please consult Appendix B."

    > Then we have two kind of instructions for the same thing - "can be" and a
    > normative "SHOULD". Hence it need to be clarified which one should prevail.

Good point.

    >> maximum SID range size is 1000.  A larger size may be requested by
    >> the authors if this recommendation is considered insufficient.  It is
    >> important to note that an additional SID range can be allocated to an
    >> existing YANG module if the initial range is exhausted."

    > I have hard time understanding the mentioning of the maximum SID range here.
    > does this mean this document sets the maximum range to 1000 but others can
    > have more? please clarify.

Each of my ANIMA modules uses around 15 SID values from a range of 50.
(that's draft-ietf-anima-constrained-voucher, which is among the first users)

I think that if you write a module that requires more than 1000 SID values
that you might be doing something wrong, and so more consultation is
warranted.

Otherwise, small ranges should be given away like the candy on the IANA desk.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide