[eppext] Ben Campbell's No Objection on draft-ietf-eppext-tmch-smd-04: (with COMMENT)
"Ben Campbell" <ben@nostrum.com> Tue, 16 February 2016 22:21 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: eppext@ietf.org
Delivered-To: eppext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F401A871C; Tue, 16 Feb 2016 14:21:02 -0800 (PST)
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>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160216222102.24096.14754.idtracker@ietfa.amsl.com>
Date: Tue, 16 Feb 2016 14:21:02 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/oVp3j8W_tB5lrc6Bb-I3F5qIaWM>
X-Mailman-Approved-At: Wed, 17 Feb 2016 08:21:56 -0800
Cc: draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, eppext@ietf.org, nkong@cnnic.cn
Subject: [eppext] Ben Campbell's No Objection on draft-ietf-eppext-tmch-smd-04: (with COMMENT)
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 22:21:02 -0000
Ben Campbell has entered the following ballot position for draft-ietf-eppext-tmch-smd-04: 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-eppext-tmch-smd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- *** Substantive Comments *** - General: I share Stephen's and Russ's concern about the lack of signature policies either here or in [ICANN-TMCH]. In particular, what does it mean for a mark to be signed? - 2.1: What is the semantic difference between <mark:name> and <mark:org>? If the latter represents an organization, should we assume the former does not? Or more specifically, does <mark:name> represent a person? Along the same lines, <mark:addr> is described in terms of an organization address. What is only <mark:name> is present? - 2.2: <mark:id> must be globally unique in relation to the repository? I _think_ this means that it must uniquely define a mark in relation to a repository. But that can also be interpreted to mean that no two mark elements can contain the same ID/repository combination. (This language occurs several times) -- <mark:treatyOrStatute>: Can you clarify the meaning of "country of the ruling"? (as opposed to the country of protection) - 2.3: -- <smd:signedMark> is described as the fragment of xml that is signed. But the text suggests the <signature> element is a child of <smd:signedMark>. Is the signature itself expected to be signed? If only part of <smd:signedMark> is signed, which parts? -- Do <smd:notBefore> and <smd:notAfter> refer to the validity of the signature, or the mark itself? -- Why is XML canonicalization a SHOULD rather than a MUST? Why might one choose not to use it? What can go wrong if you don't use it? (If the answer is that the signature validation might fail, them maybe this should be a MUST?) -- Does the reasoning for RSA-SHA256 being a SHOULD rather than a MUST imply that there are algorithms that MUST NOT be used? *** Editorial Comments *** - Abstract: It would be helpful to see a sentence describing what sort of "marks" this draft discusses in the abstract. -2.2, <mark:treatyOrStatute>, <mark:refNum>: I am not sure the intent of "number of the mark of the treaty or statute." Does the treaty or statute itself have a mark? A number? Or is just a reference number for the described mark? -6: Section numbers would be helpful for the references back into the body.
- [eppext] Ben Campbell's No Objection on draft-iet… Ben Campbell
- Re: [eppext] Ben Campbell's No Objection on draft… Gustavo Lozano