[Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
Ben Campbell <ben@nostrum.com> Wed, 02 August 2017 22:49 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47999126B6E; Wed, 2 Aug 2017 15:49:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-pceps@ietf.org, Cyril Margaria <cmargaria@juniper.net>, pce-chairs@ietf.org, cmargaria@juniper.net, pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150171415228.5759.6042228213633458080.idtracker@ietfa.amsl.com>
Date: Wed, 02 Aug 2017 15:49:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/FJISYdCBePFH75-E6E0NUYvBRFw>
Subject: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 22:49:12 -0000
Ben Campbell has entered the following ballot position for draft-ietf-pce-pceps-15: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- -3.4, step 2: "Peer validation always SHOULD include a check on whether the locally configured expected DNS name or IP address of the peer that is contacted matches its presented certificate." Why is that not a MUST? As it is, this need to at least discuss the risks involved if you don't check the identity of the peer cert (here or in the security considerations.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - I share Warren's question about why you chose STARTTLS over a dedicated port, especially since the 2nd to last paragraph in 3.2 goes out of its way to mention that. What were the tradeoffs involved that made adding the additional protocol machinery more attractive than allocating a port number? - 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as the hash algorithm for the fingerprint." Do you really intend "MUST support" (meaning you have to be able to handle sha-256, but could allow other hashes) vs "MUST use"? - 3.5: "Implementations that want to support a wide variety of trust models SHOULD expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator." "as much as possible" is pretty vague for the a 2119 SHOULD. Since the following sentences also include a SHOULD along with considerably more detail, I suggest dropping the SHOULD in this sentence, and leaving the one in the following sentence. - 3.6: Is the exponential backoff requirement part of the procedures in 5440? The wording suggests that it is not. If so, it needs elaboration here. Editorial: - 3.2, paragraph 8: s/"... PCE MUST responds with..."/ "...PCE MUST respond with..." - 3.4 : "Negotiation of mutual authentication is REQUIRED." Does that mean that the peers must elect to use mutual authentication, or that if they want to use it, they must agree to do so? (The pattern persists throughout the section, but the meaning seems more obvious for some of the others.) -3.5, 2nd to last paragraph: Please don't use 2119 keywords to describe pre-existing or external requirements. They should be reserved for the authoritative specification of a given requirement. -5, 2nd paragraph: The first sentence does not make sense.
- [Pce] Ben Campbell's Discuss on draft-ietf-pce-pc… Ben Campbell
- Re: [Pce] Ben Campbell's Discuss on draft-ietf-pc… Dhruv Dhody
- Re: [Pce] Ben Campbell's Discuss on draft-ietf-pc… Ben Campbell
- Re: [Pce] Ben Campbell's Discuss on draft-ietf-pc… Dhruv Dhody
- Re: [Pce] Ben Campbell's Discuss on draft-ietf-pc… Ben Campbell
- Re: [Pce] Ben Campbell's Discuss on draft-ietf-pc… Dhruv Dhody
- Re: [Pce] Ben Campbell's Discuss on draft-ietf-pc… Ben Campbell