[core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 13 July 2021 22:35 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0F13A0E15; Tue, 13 Jul 2021 15:35:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann <cabo@tzi.org>, jaime@iki.fi, jaime@iki.fi
X-Test-IDTracker: no
X-IETF-IDTracker: 7.34.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162621573715.1426.3300364400283622807@ietfa.amsl.com>
Date: Tue, 13 Jul 2021 15:35:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FWlR8kl5iRCjrLXdB4jTewCyKEc>
Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 13 Jul 2021 22:35:38 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-core-sid-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I think there is a new security consideration with this work that is important to document clearly -- not only do we define a new type of identifier, but we define a file format and other mechanisms for disseminating that information. An entity that's processing application/yang-data+cbor; id=sid information needs to ensure that the .sid files (or other source of SID information) it uses for such processing came from a trustworthy authority (or at least the same source as the data file). It would be possible for malicious manipulation of .sid file contents to cause a message recipient to mis-interpret the received message without any indication of such tampering. (2) Per §7.4.2, YANG SID range registries with public ranges MUST include a reference to the ".sid" file for such ranges, but the IANA-managed YANG SID range registry established by §7.5 does not, in and of itself, make such a provision. This function seems to be served by the "IETF YANG SIG Registry" created by §7.6, so we may just need to point to the one registry from the other in order to remain internally consistent. (3) There may be another inconsistency to look into; Section 7.6.2 says that: * If another ".sid" file has already allocated SIDs for this YANG module (e.g. for older or newer versions of the YANG module), the YANG items are assigned the same SIDs as in the other ".sid" file. But we are supposed to allocate a new SID for a YANG item if its semantics change in a revision of the YANG module. Perhaps it's just the "for older or newer versions of the YANG module" phrase that needs tweaking? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The yangdoctors review mentioned the structure extension from RFC 8791, and the authors (understandably) expressed reluctance to make such a large change at this stage in the process. I'll note that the DOTS WG has recently completed work on a "bis" of RFC 8782, with primary aim of replacing yang-data with structures and minimal other changes. (A yangdoctors review of a related document was sufficiently insistent that structures are the right way to do this that the WG was convinced to put in the effort.) The yangdoctors review also asked why sid-file/module-name is optional, which was tagged for follow-up. I have the same question and am interested in the outcome of the discussion amongst the authors. If SIDs are supposed to be globally unique identifiers, the reference in the YANG module to "namespace" identifiers for individual allocations is puzzling to me. The presence of a namespace would typically allow for identifier reuse across namespaces (e.g., using the same SID integer value for an identity and a data node within the same module). I see how the current list structure makes it easy to have a single flat list of all identifier/sid mappings, but if the SIDs truly are globally unique, then the "namespace" should not be a list key, and might be less confusingly described as just indicating the type for which the SID is used. (It would also be possible to have separate lists for module SIDs, identity SIDs, etc., but it's not clear that doing so is actually the right approach.) Section 1 [...] If the meaning of an item changes, for example as a result from a non- backward compatible update of the YANG module, a new SID SHOULD be assigned to it. A new SID MUST always be assigned if the new meaning of the item is going to be referenced using a SID. That predicate seems in general unknowable ("you can't prove a negative", etc.), so it's tempting to just require that if the old semantics had a SID that the new semantics get one as well. Section 4 If the scope of a sid-file-version-identifier resets when the module revision is bumped, it seems highly unlikely that we'll need 64 bits of identifier for it. Section 5, 7.3 It's not entirely clear that we need to mention the content-type/content-format in this document, as we only indicate use of the JSON encoding for the .sid file and the use of SIDs in the application/yang-data+cbor; id=sid case seems adequately described by the existing treatment in draft-ietf-core-yang-cbor. Section 7.4.1 I appreciate that the "mega-range" allocations are sized for the appropriate SI prefix :) The information associated to the Organization name should not be publicly visible in the registry, but should be available. This information includes contact email and phone number and change controller email and phone number. Available to whom? Section 7.5.2 The size of the SID range allocated for a YANG module is recommended to be a multiple of 50 and to be at least 33% above the current number of YANG items. This headroom allows assignment within the same range of new YANG items introduced by subsequent revisions. The maximum SID range size is 1000. A larger size may be requested by the authors if this recommendation is considered insufficient. [...] If there's a maximum size for a range, then asking for a larger one is pointless. Please reword to indicate the actual intent (maybe s/maximum/typical expected/ or similar). In case a SID range is required before publishing the RFC due to implementations needing stable SID values, early allocation as defined in [BCP100] can be employed. As specified in Section 4.6 of [RFC8126], RFCs and by extension documents that are expected to become an RFC fulfill the requirement for "Specification Required" stated in Section 2 of [BCP100], which allows for the early allocation process to be employed. While the first bit of this is all true, the registry here doesn't use the "Specification Required" policy for any range, and early allocations are available for the "RFC Required" range. So we should probably tweak or remove the second sentence. Section 7.6.3 Early Allocations are made with a one-year period, after which they are expired. [BCP100] indicates that at most one renewal may be made. For the SID allocation a far more lenient stance is desired. 1. An extension of a referencing documents Early Allocation should update any referenced Early Allocations to expire no sooner than the referencing document. 2. The [BCP100] mechanism allows the IESG to provide a second renewal, and such an event may prompt some thought about how the collection of documents are being processed. The first point is rather curious, since it can have no normative force (this is not a BCP that would override BCP 100) and is merely a continnation of how a more lenient stance is desired. It's rather odd to see it written in this way. The second point seems to be the only really useful part, and in practice this IESG approval of second (and more!) renewals has become rather common, to the extent where a revision of BCP 100 has been discussed to change the discussion of extensions for early renewals. This is driven by the very generous size of the SID space and the often complex and deep dependencies of YANG modules. Often a core module with many dependencies will undergo extensive review, delaying the publication of other documents. Having many *dependencies* and taking a while shouldn't delay publication of anything else; however, having many other modules dependent on a core module would be likely to do so. Appendix A IIRC the mismatch between "ietf-system@2014-08-06.yang" and the toplevel "module-revision" of "2020-02-05" was noted by an earlier reviewer, but I'll mention it here just in case I do not remember correctly. NITS Section 1 SIDs are assigned permanently, items introduced by a new revision of a YANG module are added to the list of SIDs already assigned. If the comma splice Section 5 Each .sid file contains the mapping between the different string identifiers defined by a YANG module and a corresponding numeric value called YANG SID."; singular/plural mismatch "numeric value called YANG SID"/"string identifiers"
- [core] Benjamin Kaduk's Discuss on draft-ietf-cor… Benjamin Kaduk via Datatracker
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Michael Richardson
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Carsten Bormann
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Carsten Bormann