[Sidrops] Alexey Melnikov's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT)
Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 10 April 2019 17:40 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 ECB421200EB; Wed, 10 Apr 2019 10:40:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-https-tal@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155491803396.9216.4105477992064648125.idtracker@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 10:40:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/vdng9yA7jV-_3pvQkcErbnodI04>
Subject: [Sidrops] Alexey Melnikov's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 17:40:34 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-sidrops-https-tal-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this well written document. I have a few relatively minor comments (and questions) which I think you should address: 1. Introduction This document obsoletes [RFC7730] by adding support for HTTPS URIs in a TAL. If this document obsoletes RFC 7730, then I think you need to have "Changes since RFC 7730" section (Is this a BIS document?). If it only updates it, then the above (and the obsolete header at the top of the draft) is not correct. 2.2. Trust Anchor Locator File Format In this document we define a Trust Anchor URI as a URI that can be used to retrieved a current Trust Anchor certificate. This URI MUST be either an rsync URI [RFC5781], or an HTTPS URI [RFC7230]. I think the first mention of URI still needs a reference to RFC 3986. The TAL is an ordered sequence of: 1. an optional comment section consisting of one or more lines each starting with the '#' character, followed by human readable informational UTF-8 text, and ending with a line break, Unless you think you want to use ASCII and Unicode Control characters in this field, I think you should recommend usage of RFC 5198 here. 2.3. TAL and Trust Anchor Certificate Considerations The trust anchor MUST contain a stable key. This key MUST NOT change How does "MUST contain a stable key" differ from "key MUST NOT change"? when the certificate is reissued due to changes in the INR extension(s), when the certificate is renewed prior to expiration, or for any reason other than a key change. This reads funny: “you must not change the key unless you decide to change the key”. Maybe talk about key compromise and key strength no longer being adequate instead? 4. HTTPS Considerations o This protocol does not require the use of SRV-IDs. o This protocol does not require the use of URI-IDs. I suspect this was copied from another RFC, but "does not require" is not right here, as it doesn't prevent it as an option. I think you should change "does not require the use" to "does not use"
- [Sidrops] Alexey Melnikov's No Objection on draft… Alexey Melnikov via Datatracker