[Sidrops] John Scudder's No Objection on draft-ietf-sidrops-signed-tal-15: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Wed, 15 May 2024 18:08 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A818DC18DA39; Wed, 15 May 2024 11:08:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171579652168.58708.10062785636959401163@ietfa.amsl.com>
Date: Wed, 15 May 2024 11:08:41 -0700
Message-ID-Hash: DZS3FKBIHZYXYRZM2QSC36KVVHK7ZHOX
X-Message-ID-Hash: DZS3FKBIHZYXYRZM2QSC36KVVHK7ZHOX
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-sidrops-signed-tal@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, keyur@arrcus.com, housley@vigilsec.com
X-Mailman-Version: 3.3.9rc4
Reply-To: John Scudder <jgs@juniper.net>
Subject: [Sidrops] John Scudder's No Objection on draft-ietf-sidrops-signed-tal-15: (with COMMENT)
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7N0Y33It318nnxa7Pt-G1OCMnw4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>
John Scudder has entered the following ballot position for draft-ietf-sidrops-signed-tal-15: No Objection 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the document. I have a few comments, which I hope may be helpful. ### Section 3.2.1.1, octothorpe, equivalence This field is equivalent to the comment section defined in section 2.2 of [RFC8630]. Each comment is human-readable informational UTF-8 text [RFC3629], conforming to the restrictions defined in Section 2 of [RFC5198]. The leading "#" character is omitted. What does the final sentence, about the omission of the octothorpe character, mean? Do you mean that the comment section varies from the referenced definition in RFC 8630, in that the octothorpe is not required? Do you mean something different? Maybe rephrase this to make it less ambiguous. Also, when you write “is equivalent to”, do you mean semantically equivalent? Do you mean syntactically identical? The same question applies to section 3.2.1.2. ### Section 3.2.2.4. successor This field contains the TA key to be used in place of the current key, after expiry of the relevant acceptance timer. Shouldn’t this be “if applicable“, as in 3.2.2.3? Section 7.2 implies it's optional, “It also issues a TAK object under key 'B', with key 'B' as the current key for that object, key 'A' as the predecessor key, **and no successor key**.” (emphasis added) What's more, it’s marked “optional” in the ASN.1. ### Section 6 This section includes language such as “... ensure that they will reflect the same content at all times.” The clause “at all times” appears to offer a strong consistency guarantee, forbidding even vanishingly short windows of inconsistency during the staging of new content. Is it the authors' intent that even low-probability race conditions should be precluded? Is it the case that existing implementations already take whatever steps are necessary to prevent these? (In light of the “multiple publication servers“ paragraph, I suspect the answer is "no".)
- [Sidrops] John Scudder's No Objection on draft-ie… John Scudder via Datatracker
- [Sidrops] Re: John Scudder's No Objection on draf… Tom Harrison