From nobody Wed Mar 1 05:37:27 2023 Return-Path: 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 DF70EC14CEFC; Wed, 1 Mar 2023 05:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no 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 Ym50ZL8zHQXU; Wed, 1 Mar 2023 05:37:18 -0800 (PST) Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 36BA1C14F744; Wed, 1 Mar 2023 05:37:17 -0800 (PST) Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4PRZzF2wh3zDCkd; Wed, 1 Mar 2023 14:37:13 +0100 (CET) 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 In-Reply-To: <167404882957.1138.7718323157797790477@ietfa.amsl.com> Date: Wed, 1 Mar 2023 14:37:13 +0100 Cc: The IESG , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, "core@ietf.org WG (core@ietf.org)" , jaime@iki.fi X-Mao-Original-Outgoing-Id: 699370632.94543-06ab1c177253f06a1a14bdac22aca1b4 Content-Transfer-Encoding: quoted-printable Message-Id: <788CA084-D4D5-44A5-BE88-5CD67AC809E7@tzi.org> References: <167404882957.1138.7718323157797790477@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-19: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2023 13:37:25 -0000 Hi Rob, after a bit of radio silence, I went ahead and submitted = draft-ietf-core-sid-20. My detailed responses to DISCUSS and COMMENTS are below. As I mentioned, with all the changes since -16, my view is that the WG = chairs should consider doing another working-group last call and then do = another publication request. But we still would like to know whether we will run into the same = DISCUSS! Gr=C3=BC=C3=9Fe, Carsten > On 2023-01-18, at 14:33, Robert Wilton via Datatracker = wrote: >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-core-sid-19: Discuss >=20 > [=E2=80=A6] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hi, >=20 > Updated discuss comments based on -19. >=20 > I think that my main concern is still how permanent or transient = allocated SIDs > are, particularly when YANG modules are being developed. >=20 > In particular, I think that it would be helpful for the allocated SIDs = to be > split into two (maybe three) lists: (1) Permanent allocations that = MUST never > change once allocated (e.g., if the schema path changes, the old entry = is > retained and no reallocated). (2) Temporary allocations that could = change, > e.g., when a file is being developed (either using a separate = temporary SID > range, or part of the permanent SID space allocated to the module). = (3) The > optional third section could be obsolete SIDs. I.e., ones that cannot = be > reallocated to a different path, but software generating a mapping = between SIDs > and schema paths should be able to just ignore them. Alternatively, = rather > than having a different section, entries could be marked with an = obsolete flag > in the permanent section instead. The status field we introduced in PR #141 is meant to cover (1) = =E2=80=9Cstable=E2=80=9D and (2) =E2=80=9Cunstable=E2=80=9D. (3) didn=E2=80=99t quite cross our minds; this is now covered with a = third status value, =E2=80=9Cobsolete=E2=80=9D. > When IETF drafts containing YANG modules are being developed or = updated then > the authors can decide whether new SIDs are allocated from the = permanent or > temporary sections depending on how stable they think parts of the = model are.=20 > But authors would only ever be allowed to renumber temporarily = assigned SIDs. Right. So the authority is with the authors of the YANG module. The need to keep =E2=80=9Cstable=E2=80=9D assignments actually stable = needs to be communicated to them. > I also think that having a global flag on the SID file would be = helpful to > define whether the file is the canonical SID file produced with = permission of > the module controller (owner) or generated by a third party. This = meta data > may help consumers of SIDs understand their permanence. Of course, = there is > not guarantee that the generated meta-data will necessarily be = correct. We added a status indication for the whole file: leaf sid-file-status { type enumeration { enum unpublished { description "This .sid file is unpublished [RFC8407], also called a work-in-progress or workfile. This may be when it accompanies an unpublished YANG module, or when only the .sid file itself is unpublished. The 'item' list MAY contain entries with a status value of 'unstable'."; } enum published { description "This .sid file is published, for a published YANG module. The 'item' list MUST NOT contain entries with a status value of 'unstable'."; } } default published; } > Regards, > Rob >=20 > Previous discuss comments: >=20 > There are a couple of points that I would like to see discussed and = perhaps > addressed: >=20 > (1) I would like further discussion regarding whether SIDs are bound = just to > the schema name, or the schema item definition. The draft states that = if the > definition is changed in a non-backwards-compatible (NBC) way then a = new SID > SHOULD be allocated. But I don't understand how this will work. = Given that > the .sid file would then contain exactly the same path but with = different sids > assigned (for every time the meaning of the definition changes), then = how do > consumers of the sid file know which sid to use for a given path = (given that > there is no indication in the .sid file)? Instead, I think that this = is the > wrong way to be handling NBC changes, and SIDs should be bound only to = the > schema path (i.e., the name of the item), and a new SID is only = allocated if > the name/path changes, and otherwise the same SID is used, even if the > definition changes in a non-backwards-compatible way. We now have taken the position that SIDs actually stand for the schema = name; no semantics implied. > (2) I think that this document should be clearer as to the = relationship between > SIDs and submodules (more details in the comment). This should have been fixed in -19. > (3) This draft makes use of the rc:yang-data extension. Was there any > discussion about using "YANG Data Structure Extensions" (RFC 8791) = instead, > which is meant to be a cleaner formulation of the rc:yang-data = extension, and > without the dependency on RESTCONF? I would suggest that using RFC = 8791 would > be preferable if possible. We have moved to sx:structure We still can=E2=80=99t validate the result with the tools we have at = hand. We are also not quite sure whether we have incurred another level of = JSON structure. Handling this might involve stripping that extraneous level before = calling it a SID file. (We do not want to change the overall structure of the SID file at this = late stage.) > (4) The policy in 7.4.2 for allocation a SID mega-range seems to = aiming this > towards organizations rather than individuals. The policy in 7.6 for = the "IETF > YANG SID Registry" requires an RFC. What is the mechanism if an = individual or > open source project wanted to get SIDs assigned for some of their YANG = modules? > I.e., should we be defining a separate mega-range, managed by IANA, = with just > Expert Review or Specification Required so that these modules could = use SIDs > allocated? Or do you envisage a separate entity taking up the = responsibility > for coordinating this? Megarange 0 is IANA, for IETF managed modules. We would like to have one or more organizations like comi.space [1] for = handling small fish; those web sites could get a megarange. Individuals would obtain ranges for specific modules from that = organization. Obviously, larger organizations would get their own megaranges. [1]: https://comi.space/ > Regards, > Rob >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1. Regarding the relationship between sids and submodules, I think is = best > summed up by this comment in the appendix: "Note that ".sid" files can = only be > generated for YANG modules and not for submodules." I.e., I don't = think that > sids should be allocated for the name of the submodule, and any items = within a > submodule are effectively allocated sids as part of processing the = module that > includes them. This topic should be addressed early in the document, = and > probably the existing references to submodule in the introduction and = the YANG > module can be removed. =E2=80=9CSubmodule=E2=80=9D currently occurs in: The terms imported from RFC 7950 (needs to stay) The YANG descriptions of =E2=80=9Cmodule=E2=80=9D, =E2=80=9Cidentity=E2=80= =9D, and =E2=80=9Cfeature=E2=80=9D That sentence in Appendix C. The YANG descriptions for =E2=80=9Cidentity=E2=80=9D and =E2=80=9Cfeature=E2= =80=9D sound OK to me. I=E2=80=99m not quite sure I understand the one for =E2=80=9Cmodule=E2=80=9D= =E2=80=94 where do submodules enter this discussion?=