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

Carsten Bormann <cabo@tzi.org> Fri, 29 October 2021 18:45 UTC

Return-Path: <cabo@tzi.org>
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 37A103A158B; Fri, 29 Oct 2021 11:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YizrIDjLpo6s; Fri, 29 Oct 2021 11:45:10 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A703B3A1589; Fri, 29 Oct 2021 11:45:04 -0700 (PDT)
Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Hgrvd06F1z30ZY; Fri, 29 Oct 2021 20:45:00 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <162634134491.20957.9891384677904460366@ietfa.amsl.com>
Date: Fri, 29 Oct 2021 20:45:00 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi
X-Mao-Original-Outgoing-Id: 657225900.471499-b2a8de865cf3684b02cfe4d99bdd5398
Content-Transfer-Encoding: quoted-printable
Message-Id: <0133A9EE-45A5-4240-85FC-60D30280F4B0@tzi.org>
References: <162634134491.20957.9891384677904460366@ietfa.amsl.com>
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/MuuJ3lC9nREJ31r0R3ChGqQjEUc>
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: Fri, 29 Oct 2021 18:45:15 -0000

[Duplicate copy because of mail weirdness:]

Hi Zahed,

it took us a while to process the DISCUSS positions and COMMENTS on core-sid.
We didn’t quite finish before the I-D deadline, but did submit a -17.
Link to diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-17.txt

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> This should be very easy to resolve and I want to make sure that we understand
> the situation here better -
> 
> *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 -
> 
> "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.

Indeed.  We have converged on SHOULD.  -17 says:

(Intro:)
 Assignment of SIDs to YANG items SHOULD be automated.  For more
 details how this can be achieved, and when manual interventions may
 be appropriate, see Appendix B.
 […]
 At the time of writing, a tool for automated SID file generation is
 available as part of the open-source project PYANG [PYANG].

(Informative References:)
 [PYANG]    Bjorklund, M., "An extensible YANG validator and converter
            in python", <https://github.com/mbj4668/pyang>.

(Appendix B:)
 Assignment of SIDs to YANG items SHOULD be automated.  The
 recommended process to assign SIDs is as follows: […]

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the efforts in this document.
> 
> * I support Robert Wilton's Discuss and Benjamin Kaduk's discuss no.2

We will address these in separate emails.

> One more clarification comment -
> 
> * Section 7.5.2: says -
> 
>  "  The
> 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.

This text was indeed a bit clumsy.
It now says:

 The
 SID range size SHOULD NOT exceed 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; this then
 just leads to slightly less efficient representation.

Grüße, Carsten