[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".)